Comments on End Point Blog: Starting processes at boot under SELinux

Carl, good point. The case I was describing involv...

2009-09-08T11:24:08.461-04:00

Carl, good point. The case I was describing involved only one user's crontab, so there was no difference. But if there were many crontabs under different users and they really did all fire at the same time, you're right that that'd bog things down.

Locking across different users would require coordinating the file name and ownership of the lock file, and as you note, some retrying.

Perhaps a simpler way would be in bash to sleep $(( $RANDOM / 1000 )) before starting a process, which would pause for 0-32 seconds randomly and should give breathing room.

Either way there's no escaping that a sysadmin needs to take a high-level view of what's going on at reboot time, so thanks for pointing that out.

From what I understand, the problem with @reboot c...

2009-09-08T11:09:16.259-04:00

From what I understand, the problem with @reboot cron entries is that they all fire at once, so that, for example, with the recent reboots of some of our in-house servers, many of the accounts firing up intensive daemon processes at the same time put quite a load on the servers. Ideally, one should use some kind of Highlander ("there can only be one!") mechanism to work around this issue. In perl I have done this by attempting to get a non-blocking exclusive lock on a file with flock, then executing my highlander code, finally releasing the lock. If an exclusive lock can not be obtained, sleep for a random number of seconds, then try again.