Salix Forums

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

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.

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?

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.

Salix Forums

cron.d crontabs

cron.d crontabs

Re: cron.d crontabs

Re: cron.d crontabs