search

EndPointCorp / end-point-blog

End Point Dev blog
https://www.endpointdev.com/blog/
17 stars 65 forks source link

Comments for Starting processes at boot under SELinux #197

Open phinjensen opened 6 years ago

phinjensen commented 6 years ago

Comments for https://www.endpointdev.com/blog/2009/09/starting-processes-at-boot-under/ By Jon Jensen

To enter a comment:

  1. Log in to GitHub
  2. Leave a comment on this issue.
phinjensen commented 6 years ago 
original author: carl
date: 2009-09-08T11:09:16-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.

phinjensen commented 6 years ago 
original author: Jon Jensen
date: 2009-09-08T11:24:08-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.