Does the script installer create ".lock" files in the cron directory?

Yesterday I found those lines in my syslog (which is watched by logcheck, hence I was emailed those lines) which I had not seen previously:

Jan 16 17:48:01 australis cron[1161]: (root.lock) ORPHAN (no passwd entry)
Jan 16 17:48:01 australis cron[1161]: (VIRTUALMINUSER.lock) ORPHAN (no passwd entry)

At the same time, according to the Webmin actions log, a Virtualmin user named "VIRTUALMINUSER" (placeholder) had installed "Joomla 3.2.1" via the script installer.

When I looked, I could not find these .lock files though, apparently they had been deleted again already.

The same happened last night, same syslog entries and again an installation of Joomla at the same time by that user.

I was able to reproduce the cron log behavior by creating the file /var/spool/cron/crontabs/VMINUSER.lock manually.

Just out of curiosity - since I like to know why previously unknown things happen in my log, especially if they involve "root" in some way: Is it correct that that script installer creates and later deletes those ".lock" files in the crontab directory? If so, what are they used for?

Status: 
Closed (works as designed)

Comments

Virtualmin & Webmin do indeed create those .lock files, to prevent concurrent access to the crontab files. However, they should be deleted as soon as the script install process completes.

Are you seeing these .lock files being left around for a long time after a script install completes?

Thanks for the feedback Jamie!

Nope, they were around for less than a minute, because that message appeared only once in the syslog, and cron apparently checks for these files once per minute.

It's interesting, but probably a coincidence, that I hadn't gotten those "ORPHANED" messages before, and now twice in one day when a user installed something via the script installer. I guess it just so happened that cron did its check when the script was still running.

It's no problem though; now that I know where the files came from I can just add those messages to logcheck's ignore file.

Ok, I am going to call this "working as intended" then.