Bug 216335 - an unknow entry in local locks table after crond forks
an unknow entry in local locks table after crond forks
Product: Fedora
Classification: Fedora
Component: vixie-cron (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2006-11-19 08:25 EST by Ivan Stoykov
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-20 05:35:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ivan Stoykov 2006-11-19 08:25:04 EST
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);
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.
Comment 1 Dmitry V. Levin 2006-11-28 06:00:42 EST
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.
Comment 2 Marcela Mašláňová 2006-11-28 08:36:26 EST
Yes, you're right(comment#1).
Comment 3 Dmitry V. Levin 2006-11-28 17:14:58 EST
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
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.
Comment 4 Marcela Mašláňová 2006-11-29 04:42:29 EST
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.
Comment 5 Marcela Mašláňová 2007-08-20 05:35:39 EDT
Not a bug (at least cron's bug).

Note You need to log in before you can comment on or make changes to this bug.