cron.d crontabs

Introduce yourself, create test postings or talk nonsense
Post Reply
User avatar
mimosa
Salix Warrior
Posts: 3311
Joined: 25. May 2010, 17:02
Contact:

cron.d crontabs

Post by mimosa »

According to the crond man page on /etc/cron.d:
The directory of per-user crontabs is re-parsed once every hour in any case. Any crontabs in the system directory (usually /etc/cron.d) are parsed at the same time. This directory can be used by packaging systems. When you install a package foo, it might write its own foo-specific crontab to /etc/cron.d/foo.
Presumably, reparse also occurs on boot, and also just by doing

Code: Select all

#crond
But it doesn't seem to be working.

The package in question is lockout, which I posted about here nearly three years ago when I knew even less about Linux:

http://archive09.linux.com/feature/116324

It's a Perl script to boost productivity by blocking access to the online distractions of your choice and then temporarily scrambling the root password for a set period. No-one in their right mind would do such a thing on a production system, but since a live cd will reset the root password for you if the worst does happen, it doesn't feel too dangerous to try at home.

Putting the requisite entries in root's crontab makes everything work:

Code: Select all

root[mimosa]# crontab -l                                                                                                                                                                                                                      
#
[...snip...]
# Begin custom crontab entries
#
* * * * * /usr/bin/lockout unlock 1> /dev/null
@reboot /usr/bin/lockout unlock force 1> /dev/null
(lockout only accepts the 'unlock' argument if the allotted time has expired. If not, 'force' is also needed.)

Why, though, is the app's own crontab table apparently not recognised?

Code: Select all

ls -l /etc/cron.d/lockout
-rwxr-xr-x 1 root root 236 Jul 19 17:11 /etc/cron.d/lockout
root[mimosa]# cat /etc/cron.d/lockout
# lockout needs to check every minute whether it's time to unlock
*/1 * * * *     root    /usr/bin/lockout unlock >/dev/null 2>&1

# rebooting *MUST* restore the root password
@reboot         root    /usr/bin/lockout unlock force >/dev/null 2>&1
Yes, I actually made it executable :mrgreen:

Note to anyone foolish enough to try this out: keep a root terminal open to save the bother of resetting the root password. The instructions linked to above are worth a look beforehand.
User avatar
gapan
Salix Wizard
Posts: 6349
Joined: 6. Jun 2009, 17:40

Re: cron.d crontabs

Post by gapan »

I' not sure I understand what the problem is. Is it that the command specified @reboot is not working, or that the entire crontab doesn't work at all?
Image
Image
User avatar
mimosa
Salix Warrior
Posts: 3311
Joined: 25. May 2010, 17:02
Contact:

Re: cron.d crontabs

Post by mimosa »

The entire crontab doesn't work at all. Nor did an experimental one I made myself, something like

Code: Select all

*/5 * * * * /usr/bin/touch /home/mimosa/test
My searching turned up precious few references to doing this *in Slackware*, so I wonder if it is even supported.

EDIT
One difference I have discovered is that while the other crontabs have normal environment variables, ones in /etc/cron.d do not inherit these. However, if the full path is given, this shouldn't make any difference - for instance, as in the example with touch.

I also came across a reference to the scripts in /etc/cron.d being "called from /etc/crontab". That doesn't agree with what the cron manpage says. There is no file /etc/crontab on my system.
Post Reply