|
dankirkd created JENKINS-12096:
---------------------------------- Summary: ThinBackup Worker Thread thread is still running. Execution aborted. Key: JENKINS-12096 URL: https://issues.jenkins-ci.org/browse/JENKINS-12096 Project: Jenkins Issue Type: Bug Components: thinBackup Environment: UNIX Solaris 10, Jenkins 1.415, ThinBackup 1.4 Reporter: dankirkd Assignee: Thomas Fürer We have ThinBackup set to run at 1am on Sunday mornings (i.e. Backup schedule for full backups = "0 1 * * 0"). The past run failed immediately with messages every 1 minute like the following: Dec 11, 2011 1:01:30 AM org.jvnet.hudson.plugins.thinbackup.hudson.model.AsyncPeriodicWork doRun WARNING: ThinBackup Worker Thread thread is still running. Execution aborted. Dec 11, 2011 1:02:30 AM org.jvnet.hudson.plugins.thinbackup.hudson.model.AsyncPeriodicWork doRun WARNING: ThinBackup Worker Thread thread is still running. Execution aborted. Dec 11, 2011 1:03:30 AM org.jvnet.hudson.plugins.thinbackup.hudson.model.AsyncPeriodicWork doRun WARNING: ThinBackup Worker Thread thread is still running. Execution aborted. Dec 11, 2011 1:04:30 AM org.jvnet.hudson.plugins.thinbackup.hudson.model.AsyncPeriodicWork doRun WARNING: ThinBackup Worker Thread thread is still running. Execution aborted. The problem continued until someone noticed later that day that regular build jobs were being blocked from running due to a "prepare for shutdown" block that ThinBackup triggers before running that never got canceled. The shutdown block was manually canceled to clear the job backlog. Our logs show no other entries or errors to identify the cause of the problem, or why a "ThinBackup Worker Thread thread" would be running, as if multiple ThinBackup workers were in progress and blocking each other. The first previous ThinBackup log entries were from a week before: Dec 4, 2011 11:41:10 PM org.jvnet.hudson.plugins.thinbackup.ThinBackupMgmtLink doBackupManual INFO: Starting manual backup. Dec 4, 2011 11:42:25 PM org.jvnet.hudson.plugins.thinbackup.backup.HudsonBackup backupJobs INFO: Found 79 jobs to back up. I had kicked off a manual backup, and I had seen it successfully complete in the UI, yet I see no log entry that indicates it did actually finished, either because the logging level for such messages is now FINEST, or because it never actually terminated the thread, resulting in the issue I'm reporting here. Either this is a problem with manual "Backup Now" runs, or it is a 1.4 issue. Note: I upgraded on Dec 4 from 1.2 to 1.4 in order to pickup a fix (suggested by JENKINS-9117) for backup failures never recovering and canceling the build block. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
[ https://issues.jenkins-ci.org/browse/JENKINS-12096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dankirkd resolved JENKINS-12096. -------------------------------- Assignee: dankirkd (was: Thomas Fürer) Resolution: Not A Defect After writing this defect I discovered more about the issue and feel I need to write a different defect or update JENKINS-9117 because I have a scenario that appears to indicate that ThinBackup hit an issue during backup and didn't cancel shutdown mode correctly. > ThinBackup Worker Thread thread is still running. Execution aborted. > -------------------------------------------------------------------- > > Key: JENKINS-12096 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12096 > Project: Jenkins > Issue Type: Bug > Components: thinBackup > Environment: UNIX Solaris 10, Jenkins 1.415, ThinBackup 1.4 > Reporter: dankirkd > Assignee: dankirkd > > We have ThinBackup set to run at 1am on Sunday mornings (i.e. Backup schedule for full backups = "0 1 * * 0"). The past run failed immediately with messages every 1 minute like the following: > Dec 11, 2011 1:01:30 AM org.jvnet.hudson.plugins.thinbackup.hudson.model.AsyncPeriodicWork doRun > WARNING: ThinBackup Worker Thread thread is still running. Execution aborted. > Dec 11, 2011 1:02:30 AM org.jvnet.hudson.plugins.thinbackup.hudson.model.AsyncPeriodicWork doRun > WARNING: ThinBackup Worker Thread thread is still running. Execution aborted. > Dec 11, 2011 1:03:30 AM org.jvnet.hudson.plugins.thinbackup.hudson.model.AsyncPeriodicWork doRun > WARNING: ThinBackup Worker Thread thread is still running. Execution aborted. > Dec 11, 2011 1:04:30 AM org.jvnet.hudson.plugins.thinbackup.hudson.model.AsyncPeriodicWork doRun > WARNING: ThinBackup Worker Thread thread is still running. Execution aborted. > The problem continued until someone noticed later that day that regular build jobs were being blocked from running due to a "prepare for shutdown" block that ThinBackup triggers before running that never got canceled. The shutdown block was manually canceled to clear the job backlog. > Our logs show no other entries or errors to identify the cause of the problem, or why a "ThinBackup Worker Thread thread" would be running, as if multiple ThinBackup workers were in progress and blocking each other. > The first previous ThinBackup log entries were from a week before: > Dec 4, 2011 11:41:10 PM org.jvnet.hudson.plugins.thinbackup.ThinBackupMgmtLink doBackupManual > INFO: Starting manual backup. > Dec 4, 2011 11:42:25 PM org.jvnet.hudson.plugins.thinbackup.backup.HudsonBackup backupJobs > INFO: Found 79 jobs to back up. > I had kicked off a manual backup, and I had seen it successfully complete in the UI, yet I see no log entry that indicates it did actually finished, either because the logging level for such messages is now FINEST, or because it never actually terminated the thread, resulting in the issue I'm reporting here. > Either this is a problem with manual "Backup Now" runs, or it is a 1.4 issue. Note: I upgraded on Dec 4 from 1.2 to 1.4 in order to pickup a fix (suggested by JENKINS-9117) for backup failures never recovering and canceling the build block. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
In reply to this post by JIRA noreply@jenkins-ci.org
[ https://issues.jenkins-ci.org/browse/JENKINS-12096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dankirkd reopened JENKINS-12096: -------------------------------- Assignee: Thomas Fürer (was: dankirkd) Reopening because there does still appear something that blocked this from running as it should have. Other things I have been able to see should not be related to the problem I've written about. > ThinBackup Worker Thread thread is still running. Execution aborted. > -------------------------------------------------------------------- > > Key: JENKINS-12096 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12096 > Project: Jenkins > Issue Type: Bug > Components: thinBackup > Environment: UNIX Solaris 10, Jenkins 1.415, ThinBackup 1.4 > Reporter: dankirkd > Assignee: Thomas Fürer > > We have ThinBackup set to run at 1am on Sunday mornings (i.e. Backup schedule for full backups = "0 1 * * 0"). The past run failed immediately with messages every 1 minute like the following: > Dec 11, 2011 1:01:30 AM org.jvnet.hudson.plugins.thinbackup.hudson.model.AsyncPeriodicWork doRun > WARNING: ThinBackup Worker Thread thread is still running. Execution aborted. > Dec 11, 2011 1:02:30 AM org.jvnet.hudson.plugins.thinbackup.hudson.model.AsyncPeriodicWork doRun > WARNING: ThinBackup Worker Thread thread is still running. Execution aborted. > Dec 11, 2011 1:03:30 AM org.jvnet.hudson.plugins.thinbackup.hudson.model.AsyncPeriodicWork doRun > WARNING: ThinBackup Worker Thread thread is still running. Execution aborted. > Dec 11, 2011 1:04:30 AM org.jvnet.hudson.plugins.thinbackup.hudson.model.AsyncPeriodicWork doRun > WARNING: ThinBackup Worker Thread thread is still running. Execution aborted. > The problem continued until someone noticed later that day that regular build jobs were being blocked from running due to a "prepare for shutdown" block that ThinBackup triggers before running that never got canceled. The shutdown block was manually canceled to clear the job backlog. > Our logs show no other entries or errors to identify the cause of the problem, or why a "ThinBackup Worker Thread thread" would be running, as if multiple ThinBackup workers were in progress and blocking each other. > The first previous ThinBackup log entries were from a week before: > Dec 4, 2011 11:41:10 PM org.jvnet.hudson.plugins.thinbackup.ThinBackupMgmtLink doBackupManual > INFO: Starting manual backup. > Dec 4, 2011 11:42:25 PM org.jvnet.hudson.plugins.thinbackup.backup.HudsonBackup backupJobs > INFO: Found 79 jobs to back up. > I had kicked off a manual backup, and I had seen it successfully complete in the UI, yet I see no log entry that indicates it did actually finished, either because the logging level for such messages is now FINEST, or because it never actually terminated the thread, resulting in the issue I'm reporting here. > Either this is a problem with manual "Backup Now" runs, or it is a 1.4 issue. Note: I upgraded on Dec 4 from 1.2 to 1.4 in order to pickup a fix (suggested by JENKINS-9117) for backup failures never recovering and canceling the build block. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
In reply to this post by JIRA noreply@jenkins-ci.org
|
|
In reply to this post by JIRA noreply@jenkins-ci.org
|
|||||||||||||||||
| Powered by Nabble | Edit this page |

cannot reproduce this issue.
Only if the backup is already/still running and a new backup will be trigger this happens. But I don't think that some have such a tight schedule. The other thing is that something on the filesystem could block the backup. In this case you should watch out for permission settings or parallel file operations.
in all this cases I cannot handle the issue in the backup plugin, so I decided to close this one.