Thanks for your help too Joshua. Responses are inline...
On 1/8/16, Joshua Judson Rosen <[email protected]> wrote: > On 2016-01-08 15:15, David Henderson wrote: >> >> 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. >> 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. 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. >> 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.... 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. > 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. > 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. Thanks again, Dave _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
