Here's a small tip for Slackware Linux users on laptops, especially those that have periodic tasks run via the standard cron tool.
A default full install of Slackware will include the dcron implementation of cron that runs some scheduled system maintenance tasks (like log rotation or building locate databases) for root with a config suitable for a 24/7 machine:
root@darkstar:~# 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
# properly on a newly installed system. If a script fails, run-parts will
# mail a notice to root.
#
# Run the hourly, daily, weekly, and monthly cron jobs.
# Jobs that need different timing may be entered into the crontab as before,
# but most really don't need greater granularity than this. If the exact
# times of the hourly, daily, weekly, and monthly cron jobs do not suit your
# needs, feel free to adjust them.
#
# Run hourly cron jobs at 47 minutes after the hour:
47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
#
# Run daily cron jobs at 4:40 every day:
40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null
#
# Run weekly cron jobs at 4:30 on the first day of the week:
30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
#
# Run monthly cron jobs at 4:20 on the first day of the month:
20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null
On something like a laptop, this config will almost certainly not run adequately, especially if that laptop will be in sleep mode for the above scheduled times. Fortunately though, the dcron that ships with Slackware (as of 14.2 and -current/15.0) has some anacron-like features, so one can now replace this crontab with this:
@hourly ID=hourly /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
@daily ID=daily /usr/bin/run-parts /etc/cron.daily 1> /dev/null
@weekly ID=weekly /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
@monthly ID=monthly /usr/bin/run-parts /etc/cron.monthly 1> /dev/null
The @hourly ID=hourly syntax looks strange, but that's more a consequence of dcron's implementation of these features (see crontab:)
The formats @hourly, @daily, @weekly, @monthly, and @yearly need to
update timestamp files when their jobs have been run. The timestamp
files are saved as /var/spool/cron/cronstamps/user.jobname. So for all
of these formats, the cron command needs a jobname, given by prefixing
the command with ID=jobname. (This syntax was chosen to maximize the
chance that our crontab files will be readable by other cron daemons as
well. They might just interpret the ID=jobname as a command-line envi‐
ronment variable assignment.)
Finally, as indicated above, just check /var/spool/cron/cronstamps/root.{hourly,daily,weekly,monthly} to see the last periodic run for a given root cron job. Of course, this tip isn't limited to just root/system tasks; normal users can also use these anacron-like features for their own crontabs as well.
Enjoy!
Top comments (0)