Description of problem: After crond is started an "unknown" entry appears in local locks table.It is shown by lslk utility over the filesystem where crond.pid file had been created. Version-Release number of selected component (if applicable): Tested with 4.1-44.EL4 (RHAS4u4), 4.1-64.fc6 (FC6), 4.1-11.EL3 (RHEL3u8), 4.1-58.fc5 (FC5),3.0.1-75.1(WB3u2). It seams - all versions are affected. How reproducible: start crond and then use lslk to examine locks. Steps to Reproduce: 1. install lslk package 2. stop crond 3. use lslk to see are there any "unknown" locks 4. start crond again 5. use lslk again: ex. lslk -O | grep unknown 6. check pid of running crond. It is (usually) CROND.PID - 1. Actual results: For example: # lslk -O | egrep "crond|unknown" |egrep -v grep (unknown) 6354 253,6 229417 w 0 0 0 0 0 /var (/dev/vg00/var) # ps -ef | egrep "crond|unknown" |egrep -v grep root 6355 1 0 15:05 ? 00:00:00 crond Expected results: # lslk -O | egrep "unknown|crond" | egrep -v grep crond 21999 253,0 224857 6 w 0 0 0 0 0 /var/run/crond.pid # ps -ef | egrep "crond|unknown" |egrep -v grep root 21999 1 0 14:14 ? 00:00:00 crond Additional info: Expected results shown above occured after change of cron.c:91 acquire_daemonlock(0); to cron.c:91 acquire_daemonlock(1); or "masking" it at all. Very crude, but results are correct. I don't know impact of this "patch" to complete lock acquiration though.
I think that vixie-cron-4.1-_bz216335_lock.patch as in 4.1-65 release breaks the idea of acquiring daemon lock before the fork. That is, with this patch applied crond will be unable to detect prior to fork that another crond instance is already running.
Yes, you're right(comment#1).
If you consider this "unknown" lslk behaviour as a bug, then it looks more like a kernel issue. lslk shows info based on /proc/locks file, and PID field of the crond lock entry does not change then lock is "passed" from parent crond process to child crond process. I would be very surprised if kernel would change the PID field because a lock created by flock(2) can be shared among processes. So, this is not an issue at all.
I know about it. I don't like the fact that crond has two PID - one for lock, one for running process. I still think that's problem of cron, 'cause at and many others work fine. Thanks for suggestion.
Not a bug (at least cron's bug).