Quantcast

[JIRA] (JENKINS-15099) Max number of backup sets ignored

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

[JIRA] (JENKINS-15099) Max number of backup sets ignored

JIRA noreply@jenkins-ci.org
Issue Type: Bug Bug
Affects Versions: current
Assignee: Thomas Fürer
Components: thinBackup
Created: 10/Sep/12 3:38 PM
Description:

Just spotted that thinBackup seems to ignore the 'Max number of backup' setting.
The number of backups just increases, because of this the zip archives are never created.

Reverting back to 1.5.0 and all is working again, 1.6.0 and above are all effected by this issue.

Environment: linux, jenkins 1.478
Project: Jenkins
Labels: plugin thinbackup
Priority: Major Major
Reporter: Spencer Oliver
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

[JIRA] (JENKINS-15099) Max number of backup sets ignored

JIRA noreply@jenkins-ci.org

Hi Oliver,
The 'Max number of backup' setting has nothing to do with archive older backups. Archives will be created if the the feature is enabled and more than one FULL backup is done. The older FULL backups will be archived, the last one will be not archived because this will simplifying the mechanism with DIFF backups.

I tried to reproduce your issue on Windows 7 and Kubuntu 12.04, but everything works as expected. In both cases I started jenkins with the build-in winstone servlet container, but on my productive server (Ubuntu Server 12.04) it works also as expected on a Tomcat 7.
So please double check your access rights for the backup directory. The user whose running jenkins need write access for the backup directory and of course for al the backups. If you have older backups, done with an different user it midge be that you are not able to access it for archiving or deleting it.

Please reopen this issue if you feel this is still a problem, and more information about your settings and environment.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

[JIRA] (JENKINS-15099) Max number of backup sets ignored

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org
Thomas Fürer resolved Bug JENKINS-15099 as Cannot Reproduce

tested with windows 7 and kubuntu 12.04 / ubuntu server 12.04 with the latest jenkins and thinbackup plugin available on the update server.

everything works as expected.

Change By: Thomas Fürer (10/Sep/12 4:57 PM)
Status: Open Resolved
Resolution: Cannot Reproduce
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

[JIRA] (JENKINS-15099) Max number of backup sets ignored

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

Been looking further into this as like i said before 1.50 has been working fine for a long time, just though i would upgrade to the latest version.

This is what i get in the logs with 1.6.1:
Sep 11, 2012 9:06:43 AM org.jvnet.hudson.plugins.thinbackup.ThinBackupPeriodicWork backupNow
SEVERE: Cannot perform a backup. Please be sure jenkins/hudson has write privileges in the configured backup path {0}.
java.io.FileNotFoundException: /home/jenkins/.jenkins/users/��yvind Harboe (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:120)
at org.apache.commons.io.FileUtils.doCopyFile(FileUtils.java:669)
at org.apache.commons.io.FileUtils.doCopyDirectory(FileUtils.java:929)
at org.apache.commons.io.FileUtils.copyDirectory(FileUtils.java:887)
at org.apache.commons.io.FileUtils.copyDirectory(FileUtils.java:814)
at org.jvnet.hudson.plugins.thinbackup.backup.HudsonBackup.backupRootFolder(HudsonBackup.java:292)
at org.jvnet.hudson.plugins.thinbackup.backup.HudsonBackup.backup(HudsonBackup.java:136)
at org.jvnet.hudson.plugins.thinbackup.ThinBackupPeriodicWork.backupNow(ThinBackupPeriodicWork.java:87)
at org.jvnet.hudson.plugins.thinbackup.ThinBackupMgmtLink$1.execute(ThinBackupMgmtLink.java:76)
at org.jvnet.hudson.plugins.thinbackup.hudson.model.AsyncPeriodicWork$1.run(AsyncPeriodicWork.java:54)
at java.lang.Thread.run(Thread.java:662)

The user name in question is encoded as utf8, if i remove the user from the users directory then all works as expected.
Any suggestions as to why the utf8 name is causing this issue ?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

[JIRA] (JENKINS-15099) Max number of backup sets ignored

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org
 
Spencer Oliver edited a comment on Bug JENKINS-15099

Been looking further into this as like i said before 1.50 has been working fine for a long time, just though i would upgrade to the latest version.

This is what i get in the logs with 1.6.2:
Sep 11, 2012 9:06:43 AM org.jvnet.hudson.plugins.thinbackup.ThinBackupPeriodicWork backupNow
SEVERE: Cannot perform a backup. Please be sure jenkins/hudson has write privileges in the configured backup path {0}.
java.io.FileNotFoundException: /home/jenkins/.jenkins/users/��yvind Harboe (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:120)
at org.apache.commons.io.FileUtils.doCopyFile(FileUtils.java:669)
at org.apache.commons.io.FileUtils.doCopyDirectory(FileUtils.java:929)
at org.apache.commons.io.FileUtils.copyDirectory(FileUtils.java:887)
at org.apache.commons.io.FileUtils.copyDirectory(FileUtils.java:814)
at org.jvnet.hudson.plugins.thinbackup.backup.HudsonBackup.backupRootFolder(HudsonBackup.java:292)
at org.jvnet.hudson.plugins.thinbackup.backup.HudsonBackup.backup(HudsonBackup.java:136)
at org.jvnet.hudson.plugins.thinbackup.ThinBackupPeriodicWork.backupNow(ThinBackupPeriodicWork.java:87)
at org.jvnet.hudson.plugins.thinbackup.ThinBackupMgmtLink$1.execute(ThinBackupMgmtLink.java:76)
at org.jvnet.hudson.plugins.thinbackup.hudson.model.AsyncPeriodicWork$1.run(AsyncPeriodicWork.java:54)
at java.lang.Thread.run(Thread.java:662)

The user name in question is encoded as utf8, if i remove the user from the users directory then all works as expected.
Any suggestions as to why the utf8 name is causing this issue ?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

[JIRA] (JENKINS-15099) Max number of backup sets ignored

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

Oliver,
Which user runs jenkins? Has this user access rights to this directory?

Have you tried the same with a directory without space? I'm not sure if this is the issue because I just tested it on my Kubuntu 12.04 with a directory with a space in it and I have no problem with it.

If you use Tomcat as servlet container you should look at this https://wiki.jenkins-ci.org/display/JENKINS/Tomcat. Maybe the URIEncoding takes also effect to this issue.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

[JIRA] (JENKINS-15099) Max number of backup sets ignored

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

we have a jenkins user setup - it is not a permission problem - if i rename/remove the user then all works ok.
The problem user name is 'Øyvind Harboe' - the Ø is encoded as U+00D8 (0xC3 0x98)- changing/removing this to O and again all is ok.

for info jenkins is run through the default winstone container.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

[JIRA] (JENKINS-15099) Max number of backup sets ignored

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

okay, can you tell me which encoding your system is using.
Please try to look into your jenkins_home, there will be a thinbackup.xml. Please check if the encoding of the backuppath is correct in this file.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

[JIRA] (JENKINS-15099) Max number of backup sets ignored

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

we are using en_GB.UTF-8 locale, encoding for thinbackup.xml is set to UTF-8

Just checked the jenkins system properties and java has file.encoding set to ANSI_X3.4-1968, changing to utf-8 fixes the problem.
Thanks for your help on this, not sure why the encoding was set to that value.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

[JIRA] (JENKINS-15099) Max number of backup sets ignored

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

Hello Thomas,

I've been having this issue since some days. I hope you can help.

When I check in the system information page, the file.encoding is ANSI_X3.4-1968. I am using Ubuntu 12.04 and all the codes are in UTF-8.

I tried changing the system locale to UTF-8(|LANG / LC_ALL=en_US.UTF-8), exporting -Dfile.jnu.encoding=UTF-8 to JAVA_OPTS, adding it in the .bashrc but I am still unable to change the file encoding to UTF-8 from ANSI_X3.4-1968.
Can you please help me with this.

Thanks in advance,

Change By: Sujan Karanjeet (31/Oct/12 12:05 PM)
Resolution: Cannot Reproduce
Status: Resolved Reopened
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

[JIRA] (JENKINS-15099) Max number of backup sets ignored

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org
Change By: Thomas Fürer (01/Nov/12 11:04 AM)
Status: Reopened Open
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

[JIRA] (JENKINS-15099) Max number of backup sets ignored

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org
Thomas Fürer resolved Bug JENKINS-15099 as Fixed

the cause for reopening this issue has nothing to do with the original issue, which is already fixed and accepted

Change By: Thomas Fürer (01/Nov/12 11:05 AM)
Status: Open Resolved
Resolution: Fixed
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Loading...