What are the scenarios when jenkins must be restarted. Right now, I am setting up jenkins. And, I am facing lots of issues like permission denied, no such file or directory etc. So, once I install new command used by my build process, do I need to restart jenkins? If I change any environment variable, change ownership of the file, do I need to restart jenkins?
If you're getting permissions errors, I would ensure that the user running Jenkins has read/write access to the directory/file that you're trying to modify. Make sure that this user also owns the JENKINS_HOME directory.
Typically, Jenkins shouldn't need to be restarted in any of the situations that you stated.
If you post more details about what you're trying to do, I'm sure people here can help.
Related
I am using Jenkins v1.651.3 and to schedule automated daily backup I have installed the ThinBackup plugin v1.9. But when I trigger backup manually it does not work. In the system logs all I can see is -
Sep 01, 2017 9:31:37 AM INFO org.jvnet.hudson.plugins.thinbackup.ThinBackupMgmtLink doBackupManual
Starting manual backup.
Sometimes the backup process doesn't take place because of the directory permission issue.
Make sure that your Jenkins user has the write permission to the directory where you are trying to create your backup.
I have had a similar issue like this, and in my case was as simple as the Backup directory was not correctly set or empty. If this settings of the ThinBackup is not set, when you launch it manually it does nothing, and no error at all is shown. After set a correct path, it works normally. Then my advise is to check your settings to see if something is wrong.
Thanks, #ANIL his answer saves my day.
Previously I backup Jenkins to a mount folder, but it doesn't work recently. so I use user
jenkins to log in on the Jenkins server then try the below commands
cd $BACKUP_FOLDER
bash: cd: data: Stale file handle
My jenkins user can't access this directory, but I personal user can. But anyway, this problem is caused by permission.
I have Jenkins 1.6 installed as a service on a CentOS machine.
At some point in the past the service stopped/crashed/? and Jenkins was restarted from the command line, java -jar jenkins.war, as the root user.
While it was running as root some plugins were updates/installed, and jobs created created/ran. Any new files created are now owned by the root user/group and not by the jenkins user/group.
Meaning, when the service was restarted Jenkins could not read these files. Resulting in plugins not running and most jobs not being loaded.
Manually restoring the permissions(chown, chgrp) to the plugins solves the plugin related issues.
For the jobs it's easy to spot new ones and fix them. Any existing ones that were re run and created new files are more difficult to find.
Then there may be other files which the Jenkins server created, not as part of a job or plugin which need to be changed. The errors are not always obvious, and crop up slowly over time.
Am I better adding the jenkins user to the root group? could this cause issues?
Or manually changing the permissions, hope i got them all! And fix others that come up?
Any suggestions appreciated.
In the end we manually changed the file permissions back to Jenkins. There were some immediate jobs that failed in the following days. And a few which only came up a few months later.
For the most part it worked well.
Is there a way to recover builds that were shift+deleted in Jenkins?
I saw the other thread but I think it was only for delete and not for shift+delete
Please help. I lost a few builds from my production job
Even if the build was deleted from disk, you should have the build log and you can get the Changelist at which the build was made and rebuild it.
Assuming you're running Jenkins on Windows and you performed the Shift+Delete on the job folder itself in Windows Explorer:
No.* Jenkins stores all job data in that directory and Windows deletes the files immediately using that method. You will need to restore the jobs from backup if you have them.
*Note: Unless you use a file system level recovery tool, which is out of scope for this exchange. You could ask over on Superuser.
I have a Jenkins installation which runs as a Windows Service under a specific user. Now, we want to be able to access the UI for system tests, which is not allowed with this user.
My idea was to start Jenkins from the command line (using Jenkins.war) such that it is run with allowance of desktop interaction, while still using the specific user.
However, when I run this I get an 'empty' Jenkins, so nothing is configured (no settings, no jobs). Do I have to do something special to run Jenkins from the command line retaining the settings and jobs once it has been installed as a service?
Jenkins stores its configuration in a directory (called JENKINS_HOME), whose location is generally based on the user under which Jenkins is running.
You can see where this is via: Manage Jenkins > Configure System > Home directory (at the top of the page).
To run Jenkins as another user, you need to copy the JENKINS_HOME contents to the "Home directory" value you see when running that user (probably something like c:\users\username\.jenkins).
Or you can set the JENKINS_HOME environment variable to point to the system installation directory (if you installed from the MSI, this is likely within c:\Program Files (x86)\jenkins). Then Jenkins will start up, reading the existing settings and jobs. Though in this case, you need to make sure that your user has the same access rights as the system service had.
I am trying to setup a Jenkins/Hudson CI in a distributed environment. I am curious about the following questions:
1) does the slave account need to be a root/administrator account? If lower privilege can run whats the minimum access?
2) On a slave node, does one projects jobs have access to another project files that previously built on the same node? How would you prevent this?
3) How do you secure someone from not being able to format your disk with a bat file running in a pre or post build script?
1) The slave account does not have to be root or administrator. It only needs full access to the folder you give in the "Remote FS root" field of the slave configuration.
2) Yes it does. Each project folder is owned by the user that is used to run the slave. You can access other project folders using relative paths: $WORKSPACE/../OTHER_PROJECT/. I'm not sure if there is a default way to prevent this. However, you have two options:
Delete the workspace after your build (use plugin Workspace Cleanup Plugin)
Create a separate slave/user combination for each project - the slave can be the same, but you'd have to create a separate user for each project.
3) Formatting a disk completely would require privileged access. You should not give your slave user those rights. I'm not sure whether your slave is Unix or Windows based, but either way, you should be able to prevent your user from being allowed to do any such task. Like stated in A1, the slave user only needs enough access to be able to read/write/execute in its "Remote FS root" folder.
Just out of curiosity - what OS are you running on your slave?