It gets the hostname from the slave itself by running java.net.InetAddress.getLocalHost().getHostName(). That warning indicates that for some reason the hostname is set to something that cannot actually be resolved using DNS. I don't know if there's another way to do it, but I'm all ears. The solution currently is to make sure the slave can resolve itself properly.

By the way, it does this for automatic generation of the perforce workspace name. It used to use '-hostname' as a suffix, but now it's configurable, and the hostname can simply be used as a token replacement. See the "Client name format for slaves" option.

Of course the slaves have proper hostnames and know what they are
The hostname command in shells give the correct name, as expected.
One twist here could be that:

• The Linux slave in question has 3 eth interfaces. The correct one, and the only one with a cable in, is eth3. eth0, in particular, has an IP address but no name associated.
• The Windows slave (running ipconfig /all) shows two VMWare interfaces before the real one, and only the real one has a name associated with its address.
  So perhaps it's the resolver inside Java that has a problem? That sounds a bit "fantastic", so it's probably something a lot closer to Hudson.

http://www.exampledepot.com/egs/java.net/Local.html suggests that your method does not work with virtual machines.
http://cboard.cprogramming.com/tech-board/111960-how-do-i-get-hostname-java.html agrees with your method, but also discusses multiple network interfaces a bit.

I don't work with Java, but how do you determine the "Could not get hostname" status? As far as I can read, the function getHostName() will return either the name or a string with the formatted IP address. Neither will look like a failure?

I think it's actually the getLocalHost() that fails. Possibly because of the multiple interfaces... I have heard of cases in which this method doesn't work, so it's not too outlandish.
Does the following resolve the host properly if you run it on the linux slave?

nslookup `hostname`

Yes, nslookup `hostname` does the right thing.
I tried making a small Java programme with the code that you use. On the Linux slave, getLocalHost().toString() returns a string of the form "hostname/ip-address" where ip-address is actually the wrong one (from eth0, not eth3). However, the hostname is the correct hostname. And getLocalHost().getHostName() returns the correct hostname of the slave.
On my Windows slave, both hostname and ip-address are the correct ones.

So I suspect that there's a problem either in your logic to determine whether you got a hostname or not, or something doesn't work properly when called from within Hudson?

Gah, looks like it's not the getLocalHost().getHostname() that's failing, but rather the remote call. I'm adding some code to log the full stack trace. I imagine that this could happen if the slave is having connection issues, or the workspace has been deleted.

Code changed in hudson
User: : rpetti
Path:
trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceSCM.java
http://jenkins-ci.org/commit/30125
Log:
JENKINS-6257 adding some more logging in the event that the remote call for determining the slave hostname fails

I don't have the resources to build and test a plugin - I can only handle releases.
Is there any other way I can assist? Like running commands in the scripting console or whatever its name is? (There's some way of executing Groovy scripts on the slaves, methinks)

I doubt it's connection issues; the Windows slaves are actually running on the same computer as the Master, and the Linux slave is on the same local network. Mind you, they tend to crash once (randomly) after a Hudson upgrade ...

Deleted workspaces? Maybe, but not likely. It's a consistent warning in the log. Occurs on every build of certain jobs (haven't tried to determine what they have in common).