Minor
Jenkins is launched with JENKINS_HOME set to /home/jenkins, yet for some reason that I can't find, the p4 plugin is complaining about /var/lib/jenkins.
Jul 20, 2017 4:11:28 PM org.jenkinsci.plugins.p4.client.ConnectionHelper connect SEVERE: P4: Unable to login: com.perforce.p4java.exception.ConnectionException: com.perforce.p4java.exception.ConfigException: java.nio.file.AccessDeniedException: /var/lib/jenkins Jul 20, 2017 4:11:28 PM org.jenkinsci.plugins.p4.client.ConnectionHelper <init> INFO: P4: Unable to login: com.perforce.p4java.exception.ConnectionException: com.perforce.p4java.exception.ConfigException: java.nio.file.AccessDeniedException: /var/lib/jenkins Jul 20, 2017 4:11:28 PM org.jenkinsci.plugins.p4.client.ConnectionHelper connectionRetry SEVERE: P4: Connection retry: 1 Jul 20, 2017 4:11:28 PM org.jenkinsci.plugins.p4.client.ConnectionHelper <init> INFO: P4: Connection retry: 1 Jul 20, 2017 4:11:31 PM org.jenkinsci.plugins.p4.client.ConnectionHelper connectionRetry SEVERE: P4: Connection retry giving up...
If I make /var/lib/jenkins a symlink to /home/jenkins, then the error changes to
SEVERE: P4: Unable to login: com.perforce.p4java.exception.ConnectionException: com.perforce.p4java.exception.ConfigException: java.nio.file.FileAlreadyExistsException: /var/lib/jenkins
Jenkins is launched as :
/usr/java/jdk1.8.0_141/bin/java -Dcom.sun.akuma.Daemon=daemonized -Djava.awt.headless=true -DJENKINS_HOME=/home/jenkins -jar /usr/lib/jenkins/jenkins.war --logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war --daemon --httpPort=8080 --debug=10 --handlerCountMax=100 --handlerCountMaxIdle=20
[JENKINS-45712] p4 credentials fail, can't write .p4tickets file
I guess the .p4tickets file is trying to be written out to the $HOME of the jenkins user account (regardless of the JENKINS_HOME).
On my machine, $HOME is /var/lib/jenkins, which I just symlinked to /home/jenkins. I guess I can remedy this by making jenkins user $HOME a real directory, while maintaining the $JENKINS_HOME separate. (or editing the password file and changing the jenkins user homedir to match)
So I'm not sure what to do with this bug.
It seems odd that given all the credential storing in Jenkins, that I stubbed my toe on the fact that I still need a .p4tickets file written out to disk.
I'll let p4paul decide on next steps.
EDIT: changed bug summary to match what i think issue is
Paul Allen
added a comment - P4Java requires a .p4ticket file and therefore the p4-plugin. P4Java would typically use the OS user account's home directory, but perhaps if that is not defined Java will write it to where the JVM started up.
Jenkins recently change the JENKINS_HOME as my older 1.642.3 starts up with /var/lib/jenkins. I can assure you that there are no fixed paths in the p4-plugin, so this is down to the environment.
Paul Allen
added a comment - P4Java requires a .p4ticket file and therefore the p4-plugin. P4Java would typically use the OS user account's home directory, but perhaps if that is not defined Java will write it to where the JVM started up.
Jenkins recently change the JENKINS_HOME as my older 1.642.3 starts up with /var/lib/jenkins. I can assure you that there are no fixed paths in the p4-plugin, so this is down to the environment. Paul Allen
added a comment - What type of Credential are you using?
- Perforce Password
- Perforce Ticket with ticket value
- Perforce Ticket with specified ticket file
Paul Allen
added a comment - What type of Credential are you using?
- Perforce Password
- Perforce Ticket with ticket value
- Perforce Ticket with specified ticket file Using Perforce user/password stored in Jenkins as a perforce credential.
This wouldn't have even been an issue if the P4Java had followed the $HOME dir symlink when writing out the .p4tickets file.
If I'm reading this right, rather than the symlink you can start jenkins with -Duser.home=/home/jenkins
P4Java is doing something like this:
java.io.File file = new File( <user.home> + File.separator + ".p4tickets");
try (BufferedReader reader = new BufferedReader(new FileReader(file))) {
String line = reader.readLine();
...
The JVM (because the OS says so) throws the java.nio.file.AccessDeniedException: /var/lib/jenkins
vbier
added a comment - I can confirm joel_brown's workaround. Adding "-Duser.home=/home/jenkins" to the JENKINS_JAVA_OPTIONS in /etc/sysconfig/jenkins for linux installations works just fine. Thank you.
vbier
added a comment - I can confirm joel_brown 's workaround. Adding "-Duser.home=/home/jenkins" to the JENKINS_JAVA_OPTIONS in /etc/sysconfig/jenkins for linux installations works just fine. Thank you. 
Karl Wirth
added a comment - Based on Pauls comments about this being related to Jenkins and the fact that there is a workaround, I am closing this for now.
Please feel free to reopen this if you think it was unfairly closed.
Karl Wirth
added a comment - Based on Pauls comments about this being related to Jenkins and the fact that there is a workaround, I am closing this for now.
Please feel free to reopen this if you think it was unfairly closed. I am seeing similar issue running p4sync inside docker
[Pipeline] p4sync 09:56:43 ... p4 client -o xxxx-sandbox-81 +
09:56:43 ... p4 info +
09:56:44 ... p4 info +
09:56:44 ... p4 client -i +
09:56:44 ... View: +
09:56:44 ... p4 counter change +
09:56:44 ... p4 changes -m1 -ssubmitted //vproxy-sandbox-81/... +
09:56:44 Building on Node: jd04 P4: Unable to login: com.perforce.p4java.exception.ConnectionException: com.perforce.p4java.exception.ConfigException: java.nio.file.FileSystemException: /xxx/build/.p4tickets.lck: Read-only file system P4: Connection retry: 1
/xxx/build is home directly the build user, and it does have write access
The work around is not suitable for us since we have no admin access
can we do it inside pipeline groovy script before calling p4sync?
dan tran
added a comment - - edited I am seeing similar issue running p4sync inside docker
[Pipeline] p4sync 09:56:43 ... p4 client -o xxxx-sandbox-81 +
09:56:43 ... p4 info +
09:56:44 ... p4 info +
09:56:44 ... p4 client -i +
09:56:44 ... View: +
09:56:44 ... p4 counter change +
09:56:44 ... p4 changes -m1 -ssubmitted //vproxy-sandbox-81/... +
09:56:44 Building on Node: jd04 P4: Unable to login: com.perforce.p4java.exception.ConnectionException: com.perforce.p4java.exception.ConfigException: java.nio.file.FileSystemException: /xxx/build/.p4tickets.lck: Read-only file system P4: Connection retry: 1
/xxx/build is home directly the build user, and it does have write access
The work around is not suitable for us since we have no admin access
can we do it inside pipeline groovy script before calling p4sync?
It turns out, p4sync was invoked outside of docker where home directory is marked as readonly by our system admin. Now i need to to figure out why my jenkins pipeline doing so.
let's close this again
dan tran
added a comment - - edited It turns out, p4sync was invoked outside of docker where home directory is marked as readonly by our system admin. Now i need to to figure out why my jenkins pipeline doing so.
let's close this again Paul Allen
added a comment - Hi Dan, thank you for the update.
I'm starting to do more investigation and testing around Docker usage; I presume that you are syncing files to a volume outside of docker container. Do you know what type of mount ('bind', 'mount' or 'tmpfs')? I was also wondering if you 'reuse' the volume with 'AutoClean' or 'SyncOnly' options to help reduce the sync time?
Paul Allen
added a comment - Hi Dan, thank you for the update.
I'm starting to do more investigation and testing around Docker usage; I presume that you are syncing files to a volume outside of docker container. Do you know what type of mount ('bind', 'mount' or 'tmpfs')? I was also wondering if you 'reuse' the volume with 'AutoClean' or 'SyncOnly' options to help reduce the sync time? dan tran
added a comment - Hi Allen, we just started dockerizing Perforce build with docker host has /var/lib/docker mounted on different volume an a fast SAN storage
here is our p4sync
p4sync charset: 'none', credential: 'perforce-xxxxx', format: "${clientName}", populate: forceClean(have: true, modtime: false, parallel: [enable: false, minbytes: '1024', minfiles: '1', threads: '4'], pin: '', quiet: true, replace: true, tidy: false), source: depotSource(depot)
dan tran
added a comment - Hi Allen, we just started dockerizing Perforce build with docker host has /var/lib/docker mounted on different volume an a fast SAN storage
here is our p4sync
p4sync charset: 'none' , credential: 'perforce-xxxxx' , format: "${clientName}" , populate: forceClean(have: true , modtime: false , parallel: [enable: false , minbytes: '1024' , minfiles: '1' , threads: '4' ], pin: '', quiet: true , replace: true , tidy: false ), source: depotSource(depot)
Just in case this saves some people some time.... I was using the bitinami jenkins docker image, as per comments above I added this enviroment lines to my docker-compose.yml which fixed this for me....
It should be the value thats in jenkins at Manage Jenkins -> Configure Sytem -> Home directory
environment:
- 'JAVA_OPTS=-Duser.home=/opt/bitnami/jenkins/jenkins_home'
Paul Allen
added a comment - Thank you. A great tip; I think we should add that into the documentation, just need to think of a good location.
Paul Allen
added a comment - Thank you. A great tip; I think we should add that into the documentation, just need to think of a good location. We are observing similar issues on our side... but I think our scenario might be a little bit different.
We run our Jenkins process under a service account. This service account is not expected to connect to P4.
Users (job creators, owners), do maintain their own credentials in their local store, but it's not possible to successfully create a credentials like that - as it seems the p4plugin (p4java?) uses the main Jenkins account and it's ticket - even though we provide explicit, different user/pass pair.
Jun 24, 2024 6:42:32 AM FINE org.jenkinsci.plugins.p4.client.SessionHelper P4: opened connection OK Jun 24, 2024 6:42:32 AM SEVERE org.jenkinsci.plugins.p4.client.SessionHelper connect P4: Unable to login: com.perforce.p4java.exception.ConnectionException: com.perforce.p4java.exception.ConfigException: java.nio.file.FileAlreadyExistsException: <REDACTED: jenkins service user account's home> Jun 24, 2024 6:42:32 AM INFO org.jenkinsci.plugins.p4.client.ConnectionHelper P4: Unable to login: com.perforce.p4java.exception.ConnectionException: com.perforce.p4java.exception.ConfigException: java.nio.file.FileAlreadyExistsException: <REDACTED: jenkins service user account's home> Jun 24, 2024 6:42:32 AM SEVERE org.jenkinsci.plugins.p4.client.SessionHelper connectionRetry P4: Connection retry: 1 Jun 24, 2024 6:42:32 AM INFO org.jenkinsci.plugins.p4.client.ConnectionHelper P4: Connection retry: 1 Jun 24, 2024 6:42:35 AM SEVERE org.jenkinsci.plugins.p4.client.SessionHelper connectionRetry P4: Invalid credentials. Giving up...
Is it expected behavior? Should we always authenticate the Jenkins process owner with P4 server, even though other jobs are not even planning to use these credentials?
Edit: huh. We also have a symlinked homes. And for some reason just pure "touch <jenkins process owner home>/.p4tickets" did the trick. Some symlink/file existence assessment issue?
Maciej Matczak
added a comment - - edited We are observing similar issues on our side... but I think our scenario might be a little bit different.
We run our Jenkins process under a service account. This service account is not expected to connect to P4.
Users (job creators, owners), do maintain their own credentials in their local store, but it's not possible to successfully create a credentials like that - as it seems the p4plugin (p4java?) uses the main Jenkins account and it's ticket - even though we provide explicit, different user/pass pair.
Jun 24, 2024 6:42:32 AM FINE org.jenkinsci.plugins.p4.client.SessionHelper
P4: opened connection OK
Jun 24, 2024 6:42:32 AM SEVERE org.jenkinsci.plugins.p4.client.SessionHelper connect
P4: Unable to login: com.perforce.p4java.exception.ConnectionException: com.perforce.p4java.exception.ConfigException: java.nio.file.FileAlreadyExistsException: <REDACTED: jenkins service user account's home>
Jun 24, 2024 6:42:32 AM INFO org.jenkinsci.plugins.p4.client.ConnectionHelper
P4: Unable to login: com.perforce.p4java.exception.ConnectionException: com.perforce.p4java.exception.ConfigException: java.nio.file.FileAlreadyExistsException: <REDACTED: jenkins service user account's home>
Jun 24, 2024 6:42:32 AM SEVERE org.jenkinsci.plugins.p4.client.SessionHelper connectionRetry
P4: Connection retry: 1
Jun 24, 2024 6:42:32 AM INFO org.jenkinsci.plugins.p4.client.ConnectionHelper
P4: Connection retry: 1
Jun 24, 2024 6:42:35 AM SEVERE org.jenkinsci.plugins.p4.client.SessionHelper connectionRetry
P4: Invalid credentials. Giving up...
Is it expected behavior? Should we always authenticate the Jenkins process owner with P4 server, even though other jobs are not even planning to use these credentials?
Edit: huh. We also have a symlinked homes. And for some reason just pure "touch <jenkins process owner home>/.p4tickets" did the trick. Some symlink/file existence assessment issue?
So I moved the entire /home/jenkins to /var/lib/jenkins, and ran/started jenkins again. It worked fine.
It created the following file based on how new the timestamp was:
Which makes me think that the p4 plugin, or the p4java api underneath refused to follow the symlink to write out the tickets file?
If I move the .p4tickets file away, the error returns.