Salix Forums

I am upgrading this issue to a problem (with apologies for cross posting). Regardless of the particular case, it would be great if someone could explain to me how to make this feature of cron work.

As I understand it, you can either

i) put scripts in /etc/cron.{time interval} and they will be executed as specified in root's crontab

ii) add items to root's crontab, or per user where root status isn't needed

iii) put crontab files in the directory /etc/cron.d:

According to the crond man page:

Code: Select all

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.

There is apparently a difference inthe syntax of the table in that there is a field to specify the user (e.g. root).

I assume these files can be called anything you like. However, it doesn't seem to be working for me:

http://www.salixos.org/forum/viewtopic.php?f=12&t=4778

Some information I found on crontabs suggested that a blank line or two (or not) at the end of the file might make a difference, but not in this case nor for any of my tests (such as a crontab entry to touch a file).

Couple of links that might help you,
http://www.linuxquestions.org/questions ... 175468865/
http://www.nickcoleman.org/blog/index.c ... 81115!unix

Cheers!!!

That's interesting about FREQ etc.

My specific question, though, is about crontabs placed in the cron.d directory, normally by applications. See the quote from the cron manpage above.

I suppose the question could be divided into two parts:

First, should this work? Does it work (or not work) for anyone else? For instance, if you create a file touch in /etc/cron.d, like this:

Code: Select all

#*/2 * * * *    root    touch /home/mimosa/test

and check the timestamp of test with ls?

Secondly, if it does and should work, what might I (and the application lockout) be doing wrong? Is there something that needs to be set up to make cron look in cron.d? Is my system broken? ( I doubt that, because I've had the same problem with earlier versions of Salix, perhaps right back to 13.1; so maybe something about Slack.) Have I made an obvious mistake? (I doubt that too, because lockout works for other people / other distros.)

In slackware/salix root's crontab is in /var/spool/cron/crontabs. Does it make any difference if you use that path instead of /etc/cron.d ?

Also, default permissions and access to the crontab binary are very restrictive...

Code: Select all

-rws--x--x 1 root root 12760 Sep  7  2012 /usr/bin/crontab

There is no trouble about making this work in other ways (and lockout is quite happy with an entry in root's crontab added using the official method of crontab -e). My question is about crontabs placed in /etc/cron.d, which according to the cron documentation, should work, but appear not to. So either there is something wrong locally, or I am doing it wrong, or it doesn't work in Slack.

EDIT
Also note that the crontabs in cron.d are different from the per-user and root crontabs in that the user needs to be specified - in this case, root, though for the touch test, it could be 'mimosa'. So there is an extra field.

My interest is both from curiosity, and because I'd like to make a package for lockout, for any lazy Slackers who may feel they are getting a little *too* lazy, and also don't mind being thought stupid;) . As far as I can see, it ought to work ... and so should the test using touch ...

Post the output of your cron log.

Code: Select all

cat /var/log/cron

And your crontab file that you are putting into the /etc/cron.d

Also you many want to use the absolute path to the command (i.e /usr/bin/touch)

Thanks to laprjns and everyone else who has responded.

I'm afraid I've now muddied the waters somewhat; I edited the file to remove some failed tests I tried earlier. However, to my surprise, they still appeared in the log. So I tried deleting some directories in /var/spool/cron, which was no help but generated some extra messages in the log. I tried rebooting and explicitly running crond (which I believe rereads the crontabs it looks at, which otherwise happens hourly). Having said that, here is the file and some output from the log; I've also included root's crontab (which appears to work fine) for good measure. I notice the message about sendmail, which isn't installed on my system:

Code: Select all

root[mimosa]# crontab -l
# If you don't want the output of a cron job mailed to you, you have to direct
# any output to /dev/null.  We'll do this here since these jobs should run
[...snip...]
# Begin custom crontab entries
#
* * * * * /usr/bin/lockout unlock 1> /dev/null
@reboot /usr/bin/lockout unlock force 1> /dev/null
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

*/2 * * * *     root    /usr/bin/touch /home/mimosa/test >/dev/null 2>&1
root[mimosa]# cat /var/log/cron
[...snip...]
Jul 28 12:02:01 darkstar crond[2135]: exit status 255 from user root /usr/bin/lockout unlock 1> /dev/null 
Jul 28 12:03:01 darkstar crond[3063]: exit status 127 from user root root^Iexport PATH=$PATH:/usr/bin && echo $PATH 
Jul 28 12:03:01 darkstar crond[3063]: exit status 127 from user root root^I/usr/bin/lockout unlock >/dev/null 2>&1 
Jul 28 12:03:01 darkstar crond[4365]: unable to exec /usr/sbin/sendmail: cron output for user root root^Iexport PATH=$PATH:/usr/bin && echo $PATH to /dev/null 
Jul 28 12:03:01 darkstar crond[3063]: exit status 127 from user root root^I/usr/bin/lockout unlock >/dev/null 2>&1 
Jul 28 12:03:01 darkstar crond[3063]: exit status 255 from user root /usr/bin/lockout unlock 1> /dev/null 
Jul 28 12:03:01 darkstar crond[4366]: unable to create mail file /var/spool/cron/cron.VNNVJ4/cron.root.2135: cron output for user root /usr/bin/lockout unlock 1> /dev/null to /dev/null 
Jul 28 12:03:01 darkstar crond[4367]: unable to create mail file /var/spool/cron/cron.VNNVJ4/cron.root.2135: cron output for user root root^I/usr/bin/lockout unlock >/dev/null 2>&1 to /dev/null 
Jul 28 12:03:01 darkstar crond[4368]: unable to create mail file /var/spool/cron/cron.VNNVJ4/cron.root.2135: cron output for user root root^Iexport PATH=$PATH:/usr/bin && echo $PATH to /dev/null 
Jul 28 12:03:01 darkstar crond[4369]: unable to create mail file /var/spool/cron/cron.VNNVJ4/cron.root.2135: cron output for user root root^I/usr/bin/lockout unlock >/dev/null 2>&1 to /dev/null 
Jul 28 12:03:01 darkstar crond[2135]: exit status 127 from user root root^Iexport PATH=$PATH:/usr/bin && echo $PATH 
Jul 28 12:03:01 darkstar crond[2135]: exit status 127 from user root root^I/usr/bin/lockout unlock >/dev/null 2>&1 
Jul 28 12:03:01 darkstar crond[2135]: exit status 127 from user root root^I/usr/bin/lockout unlock >/dev/null 2>&1 
Jul 28 12:03:01 darkstar crond[2135]: exit status 255 from user root /usr/bin/lockout unlock 1> /dev/null 
Jul 28 12:04:01 darkstar crond[3063]: exit status 127 from user root root^Itouch /home/mimosa/test 
Jul 28 12:04:01 darkstar crond[3063]: exit status 127 from user root root^I/usr/bin/lockout unlock >/dev/null 2>&1 
Jul 28 12:04:01 darkstar crond[3063]: exit status 127 from user root root^I/usr/bin/touch /home/mimosa/test >/dev/null 2>&1 
Jul 28 12:04:01 darkstar crond[4419]: unable to exec /usr/sbin/sendmail: cron output for user root root^Itouch /home/mimosa/test to /dev/null 
Jul 28 12:04:01 darkstar crond[3063]: exit status 127 from user root root^I/usr/bin/lockout unlock >/dev/null 2>&1 
Jul 28 12:04:01 darkstar crond[3063]: exit status 127 from user root root^Iexport PATH=$PATH:/usr/bin && echo $PATH 
Jul 28 12:04:01 darkstar crond[4423]: unable to exec /usr/sbin/sendmail: cron output for user root root^Iexport PATH=$PATH:/usr/bin && echo $PATH to /dev/null 
Jul 28 12:04:01 darkstar crond[3063]: exit status 255 from user root /usr/bin/lockout unlock 1> /dev/null 
Jul 28 12:04:01 darkstar crond[4424]: unable to create mail file /var/spool/cron/cron.VNNVJ4/cron.root.2135: cron output for user root /usr/bin/lockout unlock 1> /dev/null to /dev/null 
Jul 28 12:04:01 darkstar crond[4426]: unable to create mail file /var/spool/cron/cron.VNNVJ4/cron.root.2135: cron output for user root root^I/usr/bin/touch /home/mimosa/test >/dev/null 2>&1 to /dev/null 
Jul 28 12:04:01 darkstar crond[4425]: unable to create mail file /var/spool/cron/cron.VNNVJ4/cron.root.2135: cron output for user root root^I/usr/bin/lockout unlock >/dev/null 2>&1 to /dev/null 
Jul 28 12:04:01 darkstar crond[4428]: unable to create mail file /var/spool/cron/cron.VNNVJ4/cron.root.2135: cron output for user root root^I/usr/bin/lockout unlock >/dev/null 2>&1 to /dev/null 
Jul 28 12:04:01 darkstar crond[4429]: unable to create mail file /var/spool/cron/cron.VNNVJ4/cron.root.2135: cron output for user root root^Itouch /home/mimosa/test to /dev/null 
Jul 28 12:04:01 darkstar crond[4427]: unable to create mail file /var/spool/cron/cron.VNNVJ4/cron.root.2135: cron output for user root root^Iexport PATH=$PATH:/usr/bin && echo $PATH to /dev/null 
Jul 28 12:04:01 darkstar crond[2135]: exit status 127 from user root root^I/usr/bin/lockout unlock >/dev/null 2>&1 
Jul 28 12:04:01 darkstar crond[2135]: exit status 127 from user root root^Itouch /home/mimosa/test 
Jul 28 12:04:01 darkstar crond[2135]: exit status 127 from user root root^I/usr/bin/lockout unlock >/dev/null 2>&1 
Jul 28 12:04:01 darkstar crond[2135]: exit status 127 from user root root^I/usr/bin/touch /home/mimosa/test >/dev/null 2>&1 
Jul 28 12:04:01 darkstar crond[2135]: exit status 127 from user root root^Iexport PATH=$PATH:/usr/bin && echo $PATH 
Jul 28 12:04:01 darkstar crond[2135]: exit status 255 from user root /usr/bin/lockout unlock 1> /dev/null 
root[mimosa]# ls -l test
-rw-r--r-- 1 mimosa users 9989 Jul 28 10:50 test

mimosa wrote:My question is about crontabs placed in /etc/cron.d, which according to the cron documentation, should work, but appear not to. So either there is something wrong locally, or I am doing it wrong, or it doesn't work in Slack.

The only way i got this to work is by leaving out any reference to a users.(i.e root ) Putting the following in /etc/cron.d/test

Code: Select all

* * * * * /use/bin/touch /home/rich/testfile

resulted in a file called testfile with root:root permissions being "touched' every minute. I could not get anything to work if I included a user name prior to the command as you have.

If I created a users crontab file using crontab -e

Code: Select all

rich@torrey_pines:~$ crontab -e

using the same cron string:

Code: Select all

* * * * *  /usr/bin/touch /home/rich/testfile

resulting a file called testfile with rich:user permissions being "touched' every minute.

mimosa wrote:Also note that the crontabs in cron.d are different from the per-user and root crontabs in that the user needs to be specified - in this case, root, though for the touch test, it could be 'mimosa'. So there is an extra field.

Although I came across several examples that implied this, I could not fine any documentation that dcron (slackware 's cron app) specifically allows this. Maybe it's something that other cron apps do, but not dcron.

That was it: dcron neither wants nor allows the user to be specified in crontabs placed in /etc/cron.d (described in the crond manpage as "system" crontabs, after all).

To make a Slack package for lockout, it will need to be patched to reflect this.

I'm delighted to have solved this, which has been niggling at me for several years. Also, it's good to know how to use the /etc/cron.d directory as intended, as well as to be aware of potential portability issues arising from the use fo different cron apps.

Thanks again to all who posted.

Maybe try something like this in the /etc/cron.d/testfile

Code: Select all

* * * * * su -c "/usr/bin/touch /home/momosa/testfile" - mimosa

Salix Forums

SOLVED crontab in cron.d not recognised

SOLVED crontab in cron.d not recognised

Re: crontab in cron.d not recognised

Re: crontab in cron.d not recognised

Re: crontab in cron.d not recognised

Re: crontab in cron.d not recognised

Re: crontab in cron.d not recognised

Re: crontab in cron.d not recognised

Re: crontab in cron.d not recognised

Re: SOLVED crontab in cron.d not recognised

Re: SOLVED crontab in cron.d not recognised