[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: cron usage
From:       David Henderson <dhenderson () digital-pipe ! com>
Date:       2016-01-12 21:31:53
Message-ID: CAF-YAQy8Akqf+i3Cs3-pQJ+jozwnirN62OL_Qd_BGqf2nH2V7A () mail ! gmail ! com
[Download RAW message or body]

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


On 1/9/16, David Henderson <dhenderson@digital-pipe.com> wrote:
> 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
>
>
>
> On 1/9/16, Isaac Dunham <ibid.ag@gmail.com> wrote:
>> On Sat, Jan 09, 2016 at 02:40:21PM -0500, David Henderson wrote:
>>> 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?
>>
>> 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
>>
>
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]