Resending to devel list. Thanks for report.
-------- Forwarded Message --------
Subject: Cronie bug (handling of orphans list)
Date: Sun, 15 Feb 2015 15:45:28 -0600
From: Matt Sheldon <msheldon(a)hostgator.com>
To: mmaslano(a)redhat.com
Hi,
I noticed a bug that seems to affect all versions of cronie since the
orphan handling was added - I could be wrong; I've seen a few changelog
notes that sound related but didn't see changes associated that would
fix it.
The problem is that whenever Cronie reloads and goes through the list of
crons, adding orphaned crons to the orphans list, it doesn't check to
see that the user is already in that list. This means that if you have
100 orphaned files, and over the time crond runs random users do 100
cron edits/updates, there will be 10,000 orphans instead of just the
100. Then check_orphans iterates the list, getpwnam()ing each user. On
servers with many users, getpwnam() can be slow, so it can cause crond
to use 5-10 or more seconds of CPU time calling getpwnam() thousands of
times due to this.
I see the main purpose of orphans originally was so that user crontabs
could be loaded if the user later appeared, instead of waiting until
another crond reload. A fix for this bug would probably be to clear the
orphans list prior to loading the database during these reloads, since
the DB is about to be loaded anyway. Of course iterating the orphans
list to check for matches each time it adds a new orphan is another
option, but may be slower. Most likely I'll be doing the database clear
as a patch for our custom RPM build at Hostgator.
Thanks,
Matt Sheldon
Show replies by date