Quote:
Originally Posted by bakunin
While agreeing with the rest of your post on this (minor) issue I'd like to disagree: that depends on the system you're running on. AIX, for instance, has cron started in /etc/inittab with the "respawn" option and hence there is no need to start more than one cron processes. In my career as AIX administrator I have never seen mor than one cron process active (or any number of cron instances save 1, for that matter).
How often have you looked for multiple cron processes? Would you notice a second cron if you simply ran a "ps -ef" but were looking for something else? I can't speak to AIX since I've never worked on it. But on other systems, cron runs programs by forking itself, fiddling with the environment, and then exec'ing the program to be run. After the fork, and prior to the exec you have a 2nd process named cron. Most people tend to not schedule jobs to be run at, say, exactly at 4 minutes after midnight. Instead everyone and his brother will tend to schedule stuff,say, exactly at midnight. At these busy points, you can have dozens of cron processes waiting to exec. I have often seen several cron processes on both HP-UX and Solaris. In addition, we have a monitoring system called Big Brother that used to check for for exactly one copy of cron running. I got dragged out of bed at 2 in the morning because cron forked and Big Bro freaked. Big Bro has now been corrected.
Also I do not really approve of running "ps -ef" and looking for processing by name. Users can write their own programs and they can call one of their own programs "cron". We just had a case where a developer wrote a program to be invoked from cron. And yes, he called the program to be invoked: cron. In the case of pgrep, "pgrep -u root -x cron" would at least avoid that, but the forking problem remains.