ProcessBuilder missing "hostname"

[mdavidsaver]

It looks like the hostname executable is being run. Which in one OSX case, is absent. Surely Java provides a more portable way to query the system hostname?

2025-10-25 16:30:43 FINE [java.lang.ProcessBuilder] ProcessBuilder.start(): pid: 45234, dir: null, cmd: "hostname"
java.lang.RuntimeException: ProcessBuilder.start() debug
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1147)
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1089)
	at com.aquenos.epics.jackie.common.util.HostNameUtil.hostNameFromCommand(HostNameUtil.java:98)
	at com.aquenos.epics.jackie.common.util.HostNameUtil.getHostName(HostNameUtil.java:53)
	at com.aquenos.epics.jackie.client.ChannelAccessClientConfiguration.getHostNameFromEnvironment(ChannelAccessClientConfiguration.java:375)
	at com.aquenos.epics.jackie.client.ChannelAccessClientConfiguration.<init>(ChannelAccessClientConfiguration.java:279)
	at org.phoebus.pv.jackie.JackiePVFactory.<clinit>(JackiePVFactory.java:73)
	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method)
	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1160)

[georgweiss]

Indeed there is, though - as usual - not without pitfalls.

@smarsching, the jackie library should maybe consider using InetAddress.getLocalHost().getHostName() to determine the host name?

[smarsching]

@georgweiss Thanks for notifying me of this issue. The problem with InetAddress.getLocalHost().getHostName() is that it relies on DNS for determining the system’s hostname, which won’t always yield the correct result, and in particular it may differ from what the Channel Access C library does.

@mdavidsaver I have been successfully using this library on macOS for years (and I know several people who have done so as well). On my system (macOS 15.7.1) /bin/hostname exists and yields the correct hostname. Which version of macOS are you using, and does the command exist there and work when you run it from a shell?

[georgweiss]

The jca lib seems to adopt InetAddress.getLocalHost().getHostName(), see https://github.com/epics-base/jca/blob/master/src/core/com/cosylab/epics/caj/impl/requests/HostNameRequest.java

[smarsching]

@georgweiss Yes, I know. But this leads to situations where a client using JCA / CAJ sends a different hostname than e.g. caget on the same host, which can cause problems when using the hostname for access restrictions. This is exactly what I wanted to avoid in Jackie and why I tried to closely mirror what the C library does.

In Jackie, the logic for retrieving the hostname is implemented in HostNameUtil, and InetAddress.getLocalHost().getHostName() is used as a fallback when none of the other methods works.

So, the interesting question is why there even is a RuntimeException from ProcessBuilder.start(). According to the documentation, ProcessBuilder.start() should only throw the following exceptions (I am quoting from the docs here):

• NullPointerException if an element of the command list is null.
• IndexOutOfBoundsException if the command is an empty list (has size 0).
• SecurityException if a security manager exists and its checkExec method doesn't allow creation of the subprocess, or
  the standard input to the subprocess was redirected from a file and the security manager's checkRead method denies read access to the file, or the standard output or standard error of the subprocess was redirected to a file and the security manager's checkWrite method denies write access to the file
• UnsupportedOperationException If the operating system does not support the creation of processes.
• IOException if an I/O error occurs

The IOException is caught by the calling code and the other four exceptions should never be thrown in this context and even if they were, we should see those exceptions and not a RuntimeException.

That’s why I am curious to learn more about the context (exact macOS version, JRE type and version) where this happened. If this turns out to be a general problem and not just a bug in one specific JRE version, I am happy to implement a workaround, but at the moment it rather looks like the JRE is doing something that it should not do according to the documentation.

[smarsching]

Okay, I found out what is happening: No exception is actually raised. Rather, this is a somewhat strange behavior that might have been introduced with Java 21 (the same problem was reported here):

The code creates a new RuntimeException and logs it at debug level (see the JDK source code here. This change was introduced with a commit about two years ago, so I guess that Java 21 ist the first LTS release that exhibits it. The exception is only logged when debugging is enabled for the system logger, so I suggest checking the logging settings in order to avoid this stack trace (I won’t call it an “error” because it just is a debug message) being logged.

[georgweiss]

@smarsching, to add to my argument that InetAddress.getLocalHost().getHostName() probably should be the only strategy to get the hostname: the pva client lib also uses it and does not use whatever tool the OS offers.

Personally I think there is value in having all client libs using the same hostname lookup strategy.

As for potential differences in how caput and the Java client lib lookup hostname: maybe this should be addressed on the network/DNS side?

[mdavidsaver]

InetAddress.getLocalHost().getHostName()

So what happens is:

1. getLocalHost() calls (via. JNI) gethostname(), which is the string we would actually want.
2. It then does a lookup, returning the first IP address.
3. getHostName() then does a reverse lookup of that IP.

Clearly this reverse lookup may return something different than gethostname().

Surely Java provides a more portable way to query the system hostname?

Nope, I guess not. From searching around it looks like this is a long running pain point with java.

[mdavidsaver]

the pva client lib also uses it

With PVA, the client provided hostname is legacy. Most servers (pvAccessCPP and PVXS) will ignore this, and use only the peer IP address. So the client provided hostname is not practically relevant.

With CA, the default behavior for IOCs (RSRV) does use the client provided hostname.

[mdavidsaver]

Actually, looking more closely at the console, I do see this error on Linux as well (Debian 13). Although on exit instead of start. Not every time.

2025-10-28 13:28:21 FINE [java.lang.ProcessBuilder] ProcessBuilder.start(): pid: 3366872, dir: null, cmd: "hostname"
java.lang.RuntimeException: ProcessBuilder.start() debug
        at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1147)
        at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1089)
        at com.aquenos.epics.jackie.common.util.HostNameUtil.hostNameFromCommand(HostNameUtil.java:98)
        at com.aquenos.epics.jackie.common.util.HostNameUtil.getHostName(HostNameUtil.java:53)

hostname is present in $PATH as /usr/bin/hostname.

$ type hostname
hostname is /usr/bin/hostname

$ java --version
openjdk 21.0.9 2025-10-21
OpenJDK Runtime Environment (build 21.0.9+10-Debian-1deb13u1)
OpenJDK 64-Bit Server VM (build 21.0.9+10-Debian-1deb13u1, mixed mode, sharing)

$ git log -n1
commit ee35b3605cb7516457a6af407124894b4aa6a8db (HEAD -> master, origin/master, origin/HEAD)
Merge: b32391bdb 4d604e6e8
Author: abrahamwolk <122287276+abrahamwolk@users.noreply.github.com>
Date:   Fri Sep 12 14:55:45 2025 +0200

    Merge pull request #3544 from ControlSystemStudio/CSSTUDIO-3420
    
    CSSTUDIO-3420 Performance improvements to the Waterfall Plot widget

[georgweiss]

Not sure if this helps or confuses: on Ubuntu and Mac OS (Intel, 15.7) I cannot reproduce this. Tried Java 17,21 and 25.

[smarsching]

@mdavidsaver I am not surprised that this message is also shown on Ubuntu Linux (and probably on Windows as well). Looking at the JDK source code that I linked in my last comment, the code that generates the message seems to be platform independent.

@georgweiss I think that this is a matter of the logging settings. The message is only shown when the system logger is set to a level that includes debug messages. Remember, this message does not indicate any kind of error. The process is started just fine and this message only exists to inform a user who is debugging the software of the PID of the process that has just been created. I guess the author of this feature in the JDK decided to abuse this dummy exception (remember: it is never thrown) just so that the debug message includes a stack trace, which can sometimes be useful.

I think that the idea to log an exception in order to get a stack trace for something which is not an error was a very poor design decision by the JDK developers. Maybe they thought that it didn’t matter because people would rarely enable debug messages for the system logger or that due to the word “debug” next to the message, users would intuitively understand that this exception does not represent an error. I guess they were wrong…

[mdavidsaver]

Remember, this message does not indicate any kind of error.

If this is just a nuisance message, then please disable it by default. (every little bit helps the SNR)

[kasemir]

The Jackie implementation is of course free to do whatever it wants; we have the choice of jca or Jackie.
My leaning for a Java library, however, would be to use Java API, in this case InetAddress.getLocalHost().getHostName(), and not call out to an external /bin/hostname process. If your goal is to be 100% identical to libCA, you could call that via JNI, as was done in the initial gov.aps.jca library, but over time we've gravitated to the pure Java CAJ implementation.

[eddybl]

Remember, this message does not indicate any kind of error.

If this is just a nuisance message, then please disable it by default. (every little bit helps the SNR)

If I understand this correctly we would have to modify the JDK itself to suppress this message, so I don't think that this is an realistic option?

I have not looked at the default logging behavior of Phoebus, but as this is classified as a debug message, it will not show up on production level Phoebus deployments?