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.
Related
I have installed thinBackup plugin to back up my Jenkins, and I have configured it as follows:
So, there should be a full backup everyday after 08:00 PM, unfortunately for some reason, the scheduled backups are not running at all.
But, manual backup (by clicking the Backup Now button in the main page) works:
Jenkins has write access to the backup directory.
Can anyone let me know what could be the problem here?
FYI: I got the same problem with Periodic Backup plugin as well.
Thanks in advance.
I faced the same problem, restarting Jenkins worked for me.
I would like to upgrade Jenkins to the latest version without losing job/user configuration.
From looking through various posts the answer seems to be to replace the jenkins war directory.
I did this and although the new version seems to be in place the about dialogue still has the original version,
I think this is because the versionnumber is held in a config file outside of the war folder.
Is there a better method to upgrade.
I have the best practice with replacing jenkins.war file, content of the folder should got extracted from war file during server startup (automatically).
All configuration is stored as files in jenkins home directory.
jobs in subfolder jobs, users in users etc.
So if you will replace war file, you will dont loose the configuration or content.
You can check this for better info, looks for "Install the New Jenkins War File
"
I am sharing my experience here, as this would definitely help someone. We were on jenkins 2.138.3 and wanted to upgrade to 2.235.5 version. Now the issue we were facing is our users were getting deleted when we tried to restore the users folder from the backup of old jenkins.
Root Cause: In the jenkins upgrade the mechanism to store the users on the disk is changed. This is verified by seeing the users//config.xml of both old and new jenkins.
The first problem we faced starting the jenkins is below error
java.nio.file.DirectoryNotEmptyException: /Users/jenkins/<username>
The reason being, in the upgraded jenkins the username folder is changed. for e.g. if your username is admin then in new jenkins the folder would be something like $JENKINS_HOME/users/admin_6635238516816951048/ instead of $JENKINS_HOME/users/admin/ and this mapping is captured separately in a file
$JENKINS_HOME/users/users.xml where a sample entry would look like
<entry>
<string>admin_6635238516816951048</string>
<string>admin_6635238516816951048</string>
</entry>
Here the first String is your username and second is the folder where config.xml for your user should exists.
In our old jenkins this folder structure is not available and hence we see the error
java.nio.file.DirectoryNotEmptyException: /Users/jenkins/<username>
So, what are the steps to migrate users properly so existing credentials can be used.
Once the new jenkins war is deployed on the new jenkins, stop the jenkins.
If there exists a users.xml file in $JENKINS_HOME/users/users.xml, delete it or rename it so jenkins wont look for the new folder structure
Restore your users folder from old jenkins to new jenkins at $JENKINS_HOME location. So all your users should appear in new jenkins # $JENKINS_HOME/users folder
Start the jenkins service.
And you should be able to login with your old jenkins user's credentials.
The detailed explanation can be found at
https://www.jenkins.io/doc/upgrade-guide/2.138/#SECURITY-1072
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.
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've been reading this wiki article about the Jenkins CLI. Is there a way to rename a job through the CLI? I can't seem to find a way. An obvious workaround would be to copy a job then delete the old one, but I'm hoping there's a more straight forward way.
For what it's worth, I had to rename a larger number of jobs and was hoping on the CLI. There is no dedicated rename command. I did not try to get-job and then push a changed version up again, maybe that would work.
I have no direct access to the Jenkins machine and thus cannot mess around on the file system, like some suggested.
I resorted to a manual approach, with some clicking - maybe this is viable workaround for others: https://.../jenkins/job/OLD-JOB-NAME/rename?newName=NEW-JOB-NAME - this will give you a "are you sure" prompt, which after confirming should rename the job.
I wouldn't bother with Jenkins' own CLI. If you just navigate to the Jenkins jobs' directory on your filesystem and rename the job using the 'mv' unix command, then refresh Jenkins it should be fine. (you may have to reload the config from the disk in the Jenkins settings if refreshing doesn't work)