Binary package hint: update-motd
Description: Ubuntu 9.04
Release: 9.04
update-motd:
Installed: 1.11.1
When update-motd is executed out of /etc/cron.d, the instances are all set to run at the same minute (if they run at all). This means that up to five instances of update-motd can be started simultaneously. This causes two problems--
1. The method used to lock out simultaneous executions is not very robust. The $NEW file, which is used as a synchronization lock, is tested early in the script, but not created until later. This leaves a window open for multiple scripts to get started, and then collide with each other, ultimately messing up the resulting message of the day. At least on my machine, this error happens about half the time on each hour. The code to "nice" the process seems to be the part that opens the window the widest. Using lockfile to create a semaphore for synchronization corrects this flaw. I've created a modified version of update-motd and included it as an attachment.
2. By design, only one instance of update-motd can run at a time, and others just exit. However, this means that some of the work scheduled for the same minute doesn't get done (assuming the synchronization works correctly). But this isn't really what you want--if both the 10-minute and the hourly script are scheduled on the hour, you want both to execute serially. I can see two possible solutions to this:
a) Alter the lockfile code in the attachment to allow retries. Changing -r0 to -r5 in the attached code would allow all the instances that could possibly be scheduled to take their turns to run. The downside of this solution is that if update-motd is run manually, it could take up to 40 seconds to fail, when the lock is in place. Even the 8 second delay for a single retry is likely to be confusing to the user.
b) Alter the update-motd crontab entry in /etc/cron.d so that the instances of update-motd don't coincide. For example, one job on the 10-minute boundaries, one 1 minute after the hour, one 2 minutes after midnight each day, one 3 minutes after midnight each week, one 4 minutes after midnight each month. This change would also reduce the likelihood of multiple running instances to the point that the current method of synchronization with the $NEW file would rarely cause a problem.
Hi Stephen-
I'm working on this at the moment.
I'm curious what implementation of lockfile you're using in your script?
dpkg -S `which lockfile`?
The one from procmail, perhaps?
:-Dustin