| 2012-09-12 21:48:47 |
Greg Smolyn |
description |
Occasionally, if a file is getting overwritten during a respawn, upstart may fail to run the file. However, it will not continue to attempt respawns, it only tries one attempt.
The message seen in /var/log/messages is
Sep 12 14:39:59 my-vm kernel: [246447.263602] init: mydaemon main process ended, respawning
Sep 12 14:39:59 my-vm kernel: [246447.268044] init: Failed to spawn mydaemon main process: unable to execute: Permission denied
The scenario can be easily be reproduced by
1. start mydaemon
2. chmod a-x /usr/bin/mydaemon
3. sleep some amount of time (5-8 seconds), long enough to get it to notice it needs to respawn
4. chmod a+x /usr/bin/mydaemon
I tried without a respawn limit, as well as with a respawn limit set to an enormous number of allowable respawns.
Expected behaviour would be that upstart would continue to retry. |
Occasionally, if a file is getting overwritten during a respawn, upstart may fail to run the file. However, it will not continue to attempt respawns, it only tries one attempt.
The message seen in /var/log/messages is
Sep 12 14:39:59 my-vm kernel: [246447.263602] init: mydaemon main process ended, respawning
Sep 12 14:39:59 my-vm kernel: [246447.268044] init: Failed to spawn mydaemon main process: unable to execute: Permission denied
The scenario can be easily be reproduced by
1. start mydaemon
2. chmod a-x /usr/bin/mydaemon
3. kill `pidof mydaemon`
4. sleep some amount of time (5-8 seconds), long enough to get it to notice it needs to respawn
5. chmod a+x /usr/bin/mydaemon
I tried without a respawn limit, as well as with a respawn limit set to an enormous number of allowable respawns.
Expected behaviour would be that upstart would continue to retry. |
|
| 2012-09-12 21:53:35 |
Greg Smolyn |
description |
Occasionally, if a file is getting overwritten during a respawn, upstart may fail to run the file. However, it will not continue to attempt respawns, it only tries one attempt.
The message seen in /var/log/messages is
Sep 12 14:39:59 my-vm kernel: [246447.263602] init: mydaemon main process ended, respawning
Sep 12 14:39:59 my-vm kernel: [246447.268044] init: Failed to spawn mydaemon main process: unable to execute: Permission denied
The scenario can be easily be reproduced by
1. start mydaemon
2. chmod a-x /usr/bin/mydaemon
3. kill `pidof mydaemon`
4. sleep some amount of time (5-8 seconds), long enough to get it to notice it needs to respawn
5. chmod a+x /usr/bin/mydaemon
I tried without a respawn limit, as well as with a respawn limit set to an enormous number of allowable respawns.
Expected behaviour would be that upstart would continue to retry. |
Occasionally, if a file is getting overwritten during a respawn, upstart may fail to run the file. However, it will not continue to attempt respawns, it only tries one attempt.
The message seen in /var/log/messages is
Sep 12 14:39:59 my-vm kernel: [246447.263602] init: mydaemon main process ended, respawning
Sep 12 14:39:59 my-vm kernel: [246447.268044] init: Failed to spawn mydaemon main process: unable to execute: Permission denied
The scenario can be easily be reproduced by
1. start mydaemon
2. chmod a-x /usr/bin/mydaemon
3. kill `pidof mydaemon`
4. sleep some amount of time (5-8 seconds), long enough to get it to notice it needs to respawn
5. chmod a+x /usr/bin/mydaemon
I tried without a respawn limit, as well as with a respawn limit set to an enormous number of allowable respawns.
Expected behaviour would be that upstart would continue to retry.
NOTE:
The chmod example is a bit contrived, however seems to show the same symptoms. The actual problem is usually caused when a new file is being copied in place of the new one (through a CMake build 'make install'). (on our system the daemon notices that this update has occurred and exits, expecting to be restarted by upstart). |
|
