cron usage

Discussion:

cron usage

David Henderson

2016-01-07 19:36:44 UTC

Greetings, since I already have the cron daemon running (verified via
ps), I tried setting up an example by creating the /etc/cron.d
directory and creating a test file:

* * * * * echo 'hello world' >> /tmp/test.txt

This does not appear to be picked up by cron. So looking at the help
output, I thought I should be using the '-c' parameter:

crond -c /etc/cron.d

Once again, this appears to fail. Any thoughts on why this isn't working?

Thanks,
Dave

David Henderson

2016-01-08 13:13:03 UTC

Permalink

Good morning, are there any BB developers that monitor this list to
offer help? Is there another place that I can get this issue
resolved?

I have made sure that the ownership of the cron.d folder are both root
and carries 775 permissions. I've also made sure the files contained
within are also owned by root and also have a 775 permission set.

Thanks,
Dave

Post by David Henderson
Greetings, since I already have the cron daemon running (verified via
ps), I tried setting up an example by creating the /etc/cron.d
* * * * * echo 'hello world' >> /tmp/test.txt
This does not appear to be picked up by cron. So looking at the help
crond -c /etc/cron.d
Once again, this appears to fail. Any thoughts on why this isn't working?
Thanks,
Dave

David Henderson

2016-01-08 14:40:23 UTC

Permalink

I haven't seen any evidence of this, but do I need to create an
/etc/crontab config file? I'm looking at my Debian system and it
doesn't have anything in theres to process the cron.d directory
contents, only cron.hourly, cron.monthly, etc...

Dave

Post by David Henderson
Good morning, are there any BB developers that monitor this list to
offer help? Is there another place that I can get this issue
resolved?
I have made sure that the ownership of the cron.d folder are both root
and carries 775 permissions. I've also made sure the files contained
within are also owned by root and also have a 775 permission set.
Thanks,
Dave

David Henderson

2016-01-08 19:07:21 UTC

Permalink

Is anyone is this list anymore?

Post by David Henderson
I haven't seen any evidence of this, but do I need to create an
/etc/crontab config file? I'm looking at my Debian system and it
doesn't have anything in theres to process the cron.d directory
contents, only cron.hourly, cron.monthly, etc...
Dave

Tito

2016-01-08 20:09:55 UTC

Permalink

Post by David Henderson
Is anyone is this list anymore?

Hi,

//config: help
//config: Crond is a background daemon that parses individual crontab
//config: files and executes commands on behalf of the users in question.
//config: This is a port of dcron from slackware. It uses files of the
//config: format /var/spool/cron/crontabs/<username> files, for example:
//config: $ cat /var/spool/cron/crontabs/root
//config: # Run daily cron jobs at 4:40 every day:
//config: 40 4 * * * /etc/cron/daily > /dev/null 2>&1

Ciao,
Tito

Cathey, Jim

2016-01-08 20:08:37 UTC

Permalink

Post by David Henderson
Is anyone is this list anymore?

No. :-)

-- Jim

David Henderson

2016-01-08 20:16:30 UTC

Permalink

Post by Cathey, Jim

Post by David Henderson
Is anyone is this list anymore?

No. :-)

I was beginning to believe that! lol

David Henderson

2016-01-08 20:15:05 UTC

Permalink

Post by Tito

Hi,
//config: help
//config: Crond is a background daemon that parses individual crontab
//config: files and executes commands on behalf of the users in question.
//config: This is a port of dcron from slackware. It uses files of the
//config: $ cat /var/spool/cron/crontabs/root
//config: 40 4 * * * /etc/cron/daily > /dev/null 2>&1
Ciao,
Tito

Thanks for the reply Tito! So does the -c parameter change the
parsing directory from /var/spool/cron/crontabs, or does it specify a
'holding' directory for the individual cron jobs? Also, does that
mean that I can't implement something like an /etc/cron.d directory
where any cron jobs within it are parsed, or can I create an
/etc/crontab file to parse that directory using run-parts?

Thanks,
Dave

Joshua Judson Rosen

2016-01-08 23:46:44 UTC

Permalink

Post by David Henderson
Thanks for the reply Tito! So does the -c parameter change the
parsing directory from /var/spool/cron/crontabs,

Yes.

Post by David Henderson
or does it specify a 'holding' directory for the individual cron jobs?

The /etc/cron.d directory to which you're accustomed from Debian
doesn't hold "individual cron *jobs*", either--it holds additional
*crontab* files that are effectively all concatenated together
onto the end of the master /etc/crontab contents.

Post by David Henderson
Also, does that mean that I can't implement something like
an /etc/cron.d directory where any cron jobs within it are parsed,
or can I create an /etc/crontab file to parse that directory using run-parts?

Since you mention run-parts in the context of "cron.d" on Debian, I wonder
if you're confusing /etc/cron.d (which holds crontabs, which *are not*
run with run-parts) vs. /etc/cron.daily (which holds scripts or other
executable files, which *are* run with run-parts). Though, I did see
that the file you were putting into your "cron.d" directory was a crontab
and not a shell script..., but then you also made it executable....

You can easily create a facility like the /etc/cron.daily run-parts
directory that you're used to using on Debian--you just need to use
/var/spool/cron/crontabs/root rather than /etc/crontab (and note that
the syntax in that file is the user-crontab syntax--where the user
to run job as is implied by the name of the crontab-file,
rather than being specified in the job definitions inside).
cron.hourly, cron.monthly, and cron.weekly similarly.

Emulating the /etc/cron.d behaviour is somewhat less straightforward.
Probably you could do it by making /var/spool/cron/crontabs/root
invoke a script that maintains a self-modifying crontab--something like:

TMP_CRONTAB=$(mktemp)
echo "* * * * * $0" > $TMP_CRONTAB
cat /etc/cron.d/* >> $TMP_CRONTAB
fsync $TMP_CRONTAB
mv $TMPCRONTAB /var/spool/cron/crontabs/root

Or maybe you could do it some other way.

--
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."

David Henderson

2016-01-09 16:33:54 UTC

Permalink

Thanks for your help too Joshua. Responses are inline...

Post by Joshua Judson Rosen

Post by David Henderson
Thanks for the reply Tito! So does the -c parameter change the
parsing directory from /var/spool/cron/crontabs,

Yes.

Ok, I don't want to change that as it's pretty standard, so I'll leave
out the -c parameter.

Post by Joshua Judson Rosen

Post by David Henderson
or does it specify a 'holding' directory for the individual cron jobs?

Hmmm, I think we are both referring to the same thing, my naming
conventions appear to be wrong though. Here's from the man pages for
cron on Debian:

Additionally, in Debian, cron reads the files in the /etc/cron.d direc‐
tory. cron treats the files in /etc/cron.d as in the same way as the
/etc/crontab file (they follow the special format of that file, i.e.
they include the user field). However, they are independent of
/etc/crontab: they do not, for example, inherit environment variable
settings from it. This change is specific to Debian see the note under
DEBIAN SPECIFIC below.

Like /etc/crontab, the files in the /etc/cron.d directory are monitored
for changes.

As stated from the man page, this much be something specific to a
Debian patch of cron or likewise. I wasn't sure what BB was doing
with their cron and couldn't figure out why the files in the
/etc/cron.d directory weren't getting processed. I can see the
/etc/crontab file in Debian is what makes the /etc/cron.hourly,
cron.daily, etc directories work, but thought that /etc/cron.d was
standard behavior.

Post by Joshua Judson Rosen

Still no confusion, I was simply trying various things to see if I
could get the files in /etc/cron.d working in BB. Where run-parts
came into the picture was once I realized on Debian how the
/etc/cron.houly, cron.daily, etc directories were getting processed, I
figured I could do a work around with BB cron to work similarly to how
Debian does with /etc/cron.d. Unlike Debian though, I would have to
use run-parts to process an /etc/cron.d directory whereas Debian
parses that directory inherently apparently.

Post by Joshua Judson Rosen
You can easily create a facility like the /etc/cron.daily run-parts
directory that you're used to using on Debian--you just need to use
/var/spool/cron/crontabs/root rather than /etc/crontab (and note that
the syntax in that file is the user-crontab syntax--where the user
to run job as is implied by the name of the crontab-file,
rather than being specified in the job definitions inside).
cron.hourly, cron.monthly, and cron.weekly similarly.

After more research about the run-parts, I don't think that is going
to work as I originally intended since the scripts that would be used
in those instances would be shell scripts, not crontabs (which is what
is desired). I'll probably have to create something like you
mentioned below.

Post by Joshua Judson Rosen
Emulating the /etc/cron.d behaviour is somewhat less straightforward.
Probably you could do it by making /var/spool/cron/crontabs/root
TMP_CRONTAB=$(mktemp)
echo "* * * * * $0" > $TMP_CRONTAB
cat /etc/cron.d/* >> $TMP_CRONTAB
fsync $TMP_CRONTAB
mv $TMPCRONTAB /var/spool/cron/crontabs/root
Or maybe you could do it some other way.

Thanks again,
Dave

Isaac Dunham

2016-01-09 05:10:21 UTC

Permalink

Post by David Henderson

Post by Tito
Hi,
//config: help
//config: Crond is a background daemon that parses individual crontab
//config: files and executes commands on behalf of the users in question.
//config: This is a port of dcron from slackware. It uses files of the
//config: $ cat /var/spool/cron/crontabs/root
//config: 40 4 * * * /etc/cron/daily > /dev/null 2>&1
Ciao,
Tito

Busybox crond does not support /etc/crontab.
run-parts runs all scripts in a directory, rather than providing a way to
parse all files within it.

Now, here's a script that should add all /etc/cron.d/* jobs with proper
permissions to the right crontabs (assuming it works right; NOT TESTED!):

#!/bin/busybox ash

other_writeable () {
MODE=`stat -c %05a "$1"` || return 1
MODEG=`echo $MODE | cut -c 4`
MODEO=`echo $MODE | cut -c 5`
# if mode is 2-3 or 6+ (writeable bit is set), return 0
test $MODEG -gt 1 -a $MODEG -lt 4 || test $MODEG -gt 5 || \
test $MODEO -gt 1 -a $MODEG -lt 4 || test $MODEO -gt 5 || \
return 0
# not writeable
return 1
}

{
for F in /etc/cron.d/*
do
other_writeable "$F" || cat "$F"
done
} | grep -v '^#' | {
while read MIN H DOM MON DOW U EXEC
do
echo "$MIN $H $DOM $MON $DOW $EXEC" >> /var/spool/cron/crontabs/"$U"
done
}

Bear in mind that this script is a one-shot conversion tool; you would need
to remove duplicates manually if you ran it automatically, and there's
no rovision for removing cron jobs.

HTH,
Isaac Dunham

David Henderson

2016-01-09 16:36:49 UTC

Permalink

Good morning Isaac, thanks for your help as well. I'm going to be
working with this today to see what I can figure out and will reply
with my final solution.

Post by Isaac Dunham

Post by David Henderson
Thanks for the reply Tito! So does the -c parameter change the
parsing directory from /var/spool/cron/crontabs, or does it specify a
'holding' directory for the individual cron jobs? Also, does that
mean that I can't implement something like an /etc/cron.d directory
where any cron jobs within it are parsed, or can I create an
/etc/crontab file to parse that directory using run-parts?

Busybox crond does not support /etc/crontab.
run-parts runs all scripts in a directory, rather than providing a way to
parse all files within it.
Now, here's a script that should add all /etc/cron.d/* jobs with proper
#!/bin/busybox ash
other_writeable () {
MODE=`stat -c %05a "$1"` || return 1
MODEG=`echo $MODE | cut -c 4`
MODEO=`echo $MODE | cut -c 5`
# if mode is 2-3 or 6+ (writeable bit is set), return 0
test $MODEG -gt 1 -a $MODEG -lt 4 || test $MODEG -gt 5 || \
test $MODEO -gt 1 -a $MODEG -lt 4 || test $MODEO -gt 5 || \
return 0
# not writeable
return 1
}
{
for F in /etc/cron.d/*
do
other_writeable "$F" || cat "$F"
done
} | grep -v '^#' | {
while read MIN H DOM MON DOW U EXEC
do
echo "$MIN $H $DOM $MON $DOW $EXEC" >> /var/spool/cron/crontabs/"$U"
done
}
Bear in mind that this script is a one-shot conversion tool; you would need
to remove duplicates manually if you ran it automatically, and there's
no rovision for removing cron jobs.
HTH,
Isaac Dunham

David Henderson

2016-01-09 19:40:21 UTC

Permalink

While this is simply just a proof of concept, I could not get this to
run correctly. It had to be an obvious two-step approach, so I
created an initial root crontab and a small shell script to
dynamically create it there afterwards based on the contents of
/etc/cron.d.

Initial /var/spool/cron/crontabs/root:
* * * * * /etc/cron.d/.cron.d

/etc/cron.d/.cron.d:
#!/bin/sh
cat /etc/cron.d/* > /var/spool/cron/crontabs/root
echo "* * * * * $0" >> /var/spool/cron/crontabs/root

I can see that the actual /var/spool/cron/crontabs/root file continues
to dynamically populate based on the contents of /etc/cron.d, however,
none of the jobs listed in those files actually runs. Here's a sample
of what would be inside one of them:

* * * * * date > /tmp/test1.txt

I've also tried with and without usernames and is doesn't work either.
Any thoughts?

Thanks,
Dave

Isaac Dunham

2016-01-09 21:24:40 UTC

Permalink

Post by David Henderson
While this is simply just a proof of concept, I could not get this to
run correctly. It had to be an obvious two-step approach, so I
created an initial root crontab and a small shell script to
dynamically create it there afterwards based on the contents of
/etc/cron.d.
* * * * * /etc/cron.d/.cron.d
#!/bin/sh
cat /etc/cron.d/* > /var/spool/cron/crontabs/root
echo "* * * * * $0" >> /var/spool/cron/crontabs/root
I can see that the actual /var/spool/cron/crontabs/root file continues
to dynamically populate based on the contents of /etc/cron.d, however,
none of the jobs listed in those files actually runs. Here's a sample
* * * * * date > /tmp/test1.txt
I've also tried with and without usernames and is doesn't work either.
Any thoughts?

Looking through the source code, I see:
- cron will re-examine user crontabs every hour
- cron will parse and delete cron.update every minute if it exists
- cron.update is created by 'crontab', and is a simple list of users
whose cron jobs need to be updated.

In your example, .cron.d would need to have this line at the end:
echo 'root' >> /var/spool/cron/crontabs/cron.update

If that's not the problem, I've got no ideas.

HTH,
Isaac Dunham

David Henderson

2016-01-09 23:51:13 UTC

Permalink

Thanks for the continued support Isaac. So a bit after I wrote that
original email, I came back to the computer and saw that it had
started working. After making some adjustments to the scripts to get
times, this is what I've come up with...

The difference between when the job was processed (e.g. showing in the
/var/spool/cron/crontabs/root file) vs when the script started
outputting to the target file:
processed: Sat Jan 9 21:46:32 America 2016
started: Sat Jan 9 22:15:00 UTC 2016

Tried with a second cron.d file:
processed: Sat Jan 9 22:28:24 America 2016
started: Sat Jan 9 22:45:00 UTC 2016

Time between removing a file (the first example above) from
/etc/cron.d and processed vs when the script stopped:
processed: Sat Jan 9 22:44:40 America 2016
stopped: Sat Jan 9 23:17:00 UTC 2016

To get the processed time: echo '* * * * * date >> target.txt' >
/etc/cron.d/test1 && date > target.txt
subsequent lines were from cron: * * * * * date >> target.txt

I'll play around with your info below to see if that helps any.

Thanks,
Dave

Post by Isaac Dunham

- cron will re-examine user crontabs every hour
- cron will parse and delete cron.update every minute if it exists
- cron.update is created by 'crontab', and is a simple list of users
whose cron jobs need to be updated.
echo 'root' >> /var/spool/cron/crontabs/cron.update
If that's not the problem, I've got no ideas.
HTH,
Isaac Dunham

David Henderson

2016-01-12 21:31:53 UTC

Permalink

So I'm not sure what was up with the ~30 minute start time for cron,
but I ended up playing around with the cron.update file without any
luck. The ultimate solution was to append an additional line on the
/etc/cron.d/.cron.d file so a *very* basic version looks like:

cat /etc/cron.d/* > /var/spool/cron/crontabs/root
echo "* * * * * $0" >> /var/spool/cron/crontabs/root
crontab -u root /var/spool/cron/crontabs/root

Of course, anything in production should implement some checks like
the ownership of the file and such. Just wanted to report back in
case anyone came across this thread and found it useful.

Dave

Post by David Henderson
Thanks for the continued support Isaac. So a bit after I wrote that
original email, I came back to the computer and saw that it had
started working. After making some adjustments to the scripts to get
times, this is what I've come up with...
The difference between when the job was processed (e.g. showing in the
/var/spool/cron/crontabs/root file) vs when the script started
processed: Sat Jan 9 21:46:32 America 2016
started: Sat Jan 9 22:15:00 UTC 2016
processed: Sat Jan 9 22:28:24 America 2016
started: Sat Jan 9 22:45:00 UTC 2016
Time between removing a file (the first example above) from
processed: Sat Jan 9 22:44:40 America 2016
stopped: Sat Jan 9 23:17:00 UTC 2016
To get the processed time: echo '* * * * * date >> target.txt' >
/etc/cron.d/test1 && date > target.txt
subsequent lines were from cron: * * * * * date >> target.txt
I'll play around with your info below to see if that helps any.
Thanks,
Dave

Post by Isaac Dunham

Doug Clapp

2016-01-08 21:41:34 UTC

Permalink

I'm using busybox crond and crontab on a Puppy PC distribution. The
crond runs with no parameters. I use crontab to create/edit my cron
file. The file itself is indeed in
/var/spool/cron/crontabs/user
(where "user" is the owner of the crontab file). I've been using this
for several years and so far it has worked as I expect. I haven't used
the -c parameter to crond or crontab but as I read the help info it
means crond and crontab use that path instead of
/var/spool/cron/crontabs. When you speak of "cron jobs" it reminds me
of the way "at" jobs were stored when I used it under several flavors of
Unix. Are you sure you aren't conflating the two (cron and at)?

As to whether anybody still watches the list - some people have jobs and
other commitments so they may not read it every day. Some are not
necessarily interested in or expert in a given area (cron in this case),
some may wait to see if any other subscriber has a better response
first, some may have other reasons for not responding right away.

Doug Clapp

David Henderson

2016-01-08 22:23:26 UTC

Permalink

Thanks for the response Doug! I'll answer inline below...

Post by Doug Clapp
I'm using busybox crond and crontab on a Puppy PC distribution. The
crond runs with no parameters. I use crontab to create/edit my cron
file. The file itself is indeed in
/var/spool/cron/crontabs/user
(where "user" is the owner of the crontab file). I've been using this
for several years and so far it has worked as I expect. I haven't used
the -c parameter to crond or crontab but as I read the help info it
means crond and crontab use that path instead of
/var/spool/cron/crontabs.

Ok, that's what I was thinking too. The help I found for the commands
of busybox are not very indepth so it's hard to decipher what is meant
at times (https://busybox.net/downloads/BusyBox.html). I don't want
to change that location if that truly is what's going on. If anyone
else can verify I would appreciate it.

Post by Doug Clapp
When you speak of "cron jobs" it reminds me
of the way "at" jobs were stored when I used it under several flavors of
Unix. Are you sure you aren't conflating the two (cron and at)?

No confusion, I am aware of both 'at' and 'cron'. On my Debian
system, there's an /etc/cron.d directory that will automatically
process files placed in it without having to make adjustments to a
particular accounts crontab. Kinda like a system-wide cron job
storage directory. Obviously this needs to be used with caution and
most likely not by users. I'm trying to mimic that on the system I'm
working on with BB.

Is anyone aware if the BB cron daemon uses an /etc/crontab config
file? I might be able to create something similiar to Debian using
that file.

Post by Doug Clapp
As to whether anybody still watches the list - some people have jobs and
other commitments so they may not read it every day. Some are not
necessarily interested in or expert in a given area (cron in this case),
some may wait to see if any other subscriber has a better response
first, some may have other reasons for not responding right away.

I can definitely understand this, that's why I was attempting to
provide as much information as I uncovered it via subsequent posts.
And also gave it days before attempting to reach out again. Of course
I'm also thankful for those who can help (as you can see by all of my
replies).

Dave