Must be some corner case that you are hitting in your configuration, unfortunately I have no idea what it could be. For whatever reason, hudson can't run the command in your job's workspace directory. If you aren't using ${hostname} in your slave client name, then it's safe for you to ignore it.

I believe most of my jobs use the default (blank) which I'm not really sure what means ... Use the given clientname?
Anyway, all jobs appear to be working fine - it just bugs me that there's this error message showing up as often ...

That's odd. It should never be blank. If it is somehow set to be blank, then it will set it to one of the defaults based on the old settings if they are available.

One of my remote slaves that I control in another office seems to be exhibiting the same behavior... but I can't be sure if that's because it has a bogus hostname or not. In any case, I might change the plugin so it won't attempt to get the hostname if it doesn't have to.

I'm talking about the client name in the "Advanced" section, which can e.g. be ${clientname}. I believe most of my jobs were created before that field was created, so they have a blank value for it. That is documented to mean something, which of course I cannot remember right now. Is this (part of) the problem?
The recommended default, AFAIR, is ${clientname}-${hash} which apparently does not stop the master from polling.

I'm also referring to that client name. Any job that was created before this option was added will either use the default of ${basename}${hash}, ${basename} or ${basename}${hostname} based on what the old settings were. It should NEVER appear to be blank... This value is used to determine which client to use for the slaves, and the hostname of the slave can be used in the substitution. While I don't believe this is causing your problem directly, if the field appears to be blank then I suspect there may be something wrong elsewhere in your setup.

Alright, I'll check my settings. If I find blanks, what kind of "something wrong" should I be looking for?

If I submit a new job with a blank value, what will it become? ${basename}, I presume?

Corrupt class files in the plugin installation directory, or even hudson itself are the only things I can think of. There could possibly be something amiss in the code, but it's pretty simple: If it's blank or null, return a sensible default instead. In any case, this problem itself is probably not causing the issue, but may be indicative of a deeper problem with your installation.

As I mentioned, the default depends on the settings the job had before you upgraded. ${basename} if "Don't Rename Client" was checked, ${basename}${hostname} if "Use Old Client Name" was checked, and ${basename}${hash} otherwise.

I've just upgraded to 1.360 and p4 plugin 1.1.0. As a part of the upgrade I deleted all .hpi files and the extracted subdirectories in 'plugin', as well as the entire 'war' directory of hudson itself. Should be a clean good installation now.
But I still have the same problem. In fact, it appears to be logged for ALL polling activity (noticed that a couple of days ago, so not just 1.1.0) on slaves.
I checked all jobs for one of the slaves that it cannot determine the name of. All jobs had ${basename} as their slave client name.
I'll attach a piece of the log.

Roughly two minutes of log (383 lines), showing Perforce problems with determining slave hostnames when polling. Actual slave names have been deleted; it happened on 2 or 3 different slaves. I believe a couple of builds were triggered in this period - they all work fine wrt Perforce.

Code changed in hudson
User: : rpetti
Path:
trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceSCM.java
http://jenkins-ci.org/commit/31632
Log:
[FIXED JENKINS-6257] create a workspace filepath for running GetHostname if none is provided during polling