SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
First, crond keeps crashing after working for a while (until now). If anyone knows of a problem with the normal Slackware 15 crond, please let me know.
Second, last night, I restarted crond a few minutes before 0200, when it was supposed to run this from root's crontab:
0 2 * * * /usr/bin/calendar -a
When, as root, I ran calendar -a, it worked fine.
0200 came and went, no email sent about a calendar entry for a medical appointment today (that I'd forgotten about, and didn't get the labs done for because cron didn't send me the reminder to do those. I also missed an important injection (B-12). I use calendar(5) and /usr/bin/calendar to keep track of medical stuff that my post-cancer #1 memory does a terrible job of remembering. I need cron to be working flawlessly.
Does anyone know of any existing problems with the standard Slackware 15
crond and cron? Or, is there a better version (perhaps from the GNU
archives, etc.)?
Cron is generally pretty stable, I don't know of any problems with it on Slack 15 in particular (although Slackware does not use cronie like a lot of other distros, but dcron).
However, you mentioned that the command runs outside of cron but not from within it, and I've seen that before. It happens because the environment that the cron command runs in is limited, and will not be the same as when you run a command interactively from a shell. The workaround is to put your command in a wrapper shell script that sets all the proper environment vars it needs, and run the wrapper script via cron. You can also install system/cronie from slackbuilds.org, which allows you to set environment variables in the crontab itself.
If you are curious about the cron environment, put the printenv command in your cron, and redirect the output to a temp file you can look at.
fcrontab -l -u systab
## System Wide Crontab
##
## This file defines a number of jobs for the cron daemon to do that pretain to
## the system as a whole. Most all of the non-personal system-level things are
## to be kept in this file for simple, one-place organization.
##
## NOTE: MAKE SURE THIS FILE AND FCRON'S INTERNAL COPY SYNC!!
## (Or funny, unexpected things might happen)
# No mail for any of these by default, but definately report
# if the command wasn't run for some reason
!mail(false),noticenotrun(true),nice(18)
# Enter a "Restart" mark in the logfile for sadc and make sure that
# logfile is created just after midnight each day so that the 'sar'
# command with always produce output instead of 'file not found'
& 1 0 * * * /usr/lib64/sa/sadc -
# Generate a summary of process accounting each midnight
# This is only the report generation, and is still needed.
%nightly * 23 /usr/lib64/sa/sa2 -A
# Keep DB for nsswitch usage up to date with /etc/ files
%nightly * 23 make -C /var/db
# Update the man page data base for new pages.
# Command for mandb 'man'
%middaily * 12-13 mandb -q
# makewhatis for regular 'man'
#%middaily * 12-13 /usr/sbin/makewhatis -s '0p 1p 3p 1 2 3 4 5 6 7 8 9 n' -w
# Run updatedb daily, too. This is for the "locate" command.
# It's database is at /var/lib/mlocate/mlocate.db
%nightly * 4-5 /usr/bin/updatedb --prunepaths="/tmp /sys /var/tmp /proc /dev /root /mnt /lost+found /home /run /media"
# Logrotate. Rotate old logs each night
%nightly * 5-6 /usr/sbin/logrotate /etc/logrotate.conf
# UUCP. Have the daemon check for any queued jobs/mail/news to be sent.
# Check for work for system "atr2". Only startup if work to do.
#%hourly * /usr/sbin/uucico --system atr2 --ifwork --quiet
# Scan the system font dirs nightly to keep cache fresh
%nightly * 4-5 fc-cache -r -s /usr/share/fonts/OTF /usr/share/fonts/TTF
## Complex Fixed System Jobs
##
## These jobs run as one-shot jobs from the /etc/cron.d directory
## and only appear in the system crontab. Most of these tasks are
## implemented as scripts that do a task involving many lines of
## code that can't well be written as a normal fcron job
##
%nightly * 2-3 /usr/bin/run-parts /etc/cron.d
## EOF
Logs look like so:
Code:
Jul 19 05:00:01 atr2 fcron[20729]: Job '/usr/sbin/logrotate /etc/logrotate.conf' completed
Jul 19 12:00:00 atr2 fcron[945]: Job 'mandb -q' started for user systab (pid 946)
Jul 19 12:00:04 atr2 fcron[945]: Job 'mandb -q' completed
Jul 19 23:00:00 atr2 fcron[27746]: Job 'make -C /var/db' started for user systab (pid 27747)
Jul 19 23:00:00 atr2 fcron[27748]: Job '/usr/lib64/sa/sa2 -A' started for user systab (pid 27749)
Jul 19 23:00:00 atr2 fcron[27746]: Job 'make -C /var/db' completed
Jul 19 23:00:00 atr2 fcron[27748]: Job '/usr/lib64/sa/sa2 -A' completed
Jul 20 00:01:00 atr2 fcron[30577]: Job '/usr/lib64/sa/sadc -' started for user systab (pid 30578)
Jul 20 00:01:00 atr2 fcron[30577]: Job '/usr/lib64/sa/sadc -' completed
Jul 20 02:00:00 atr2 fcron[3823]: Job '/usr/bin/run-parts /etc/cron.d' started for user systab (pid 3824)
Jul 20 02:00:00 atr2 run-parts[3824]: (/etc/cron.d) starting certwatch
Jul 20 02:00:00 atr2 run-parts[3824]: (/etc/cron.d) finished certwatch
Jul 20 02:00:00 atr2 fcron[3823]: Job '/usr/bin/run-parts /etc/cron.d' completed
Jul 20 04:00:00 atr2 fcron[8027]: Job 'fc-cache -r -s /usr/share/fonts/OTF /usr/share/fonts/TTF' started for user systab (pid 8028)
Jul 20 04:00:00 atr2 fcron[8029]: Job '/usr/bin/updatedb --prunepaths="/tmp /sys /var/tmp /proc /dev /root /mnt /lost+found /home /run /media"' started for user systab (pid 8030)
Jul 20 04:00:01 atr2 fcron[8027]: Job 'fc-cache -r -s /usr/share/fonts/OTF /usr/share/fonts/TTF' completed
Jul 20 04:00:03 atr2 fcron[8029]: Job '/usr/bin/updatedb --prunepaths="/tmp /sys /var/tmp /proc /dev /root /mnt /lost+found /home /run /media"' completed
Jul 20 05:00:00 atr2 fcron[9970]: Job '/usr/sbin/logrotate /etc/logrotate.conf' started for user systab (pid 9971)
thinknix remained me of a trick. Not really a trick but probably calendar is not in the PATH of crond so you should use full path to it.
That goes to everything you can in crond. It's better to use full path instead of just application name.
I've used the default crontab with not too much problems. In my case, I just put stuff in /etc/cron.hourly or /etc/cron.weekly and cron picks it up (crontab -l shows how its setup).
Does anyone know of any existing problems with the standard Slackware 15 crond and cron?
Nope. It's been bulletproof here... running 24x7 without any issues at all since 15.0 was released.
Quote:
Originally Posted by tmmukunn
I've used the default crontab with not too much problems. In my case, I just put stuff in /etc/cron.hourly or /etc/cron.weekly and cron picks it up (crontab -l shows how its setup).
Yeah, same here. I've found the default cron configuration to be excellent.
For things which I want to run at specific times, I use "at," which is running by default on a full/default installation of Slackware.
As an example: I have a script under /etc/cron.daily called "redundant" which makes a redundant copy of my files at 6:00pm every day.
The content of my /etc/cron.daily/redundant script is:
That's it. No need to edit crontab or restart cron. As I said above, it has been running flawlessly for almost 18 months. At 4:40am when cron runs its daily jobs, this job gets scheduled for 6:00pm and then runs at 6:00pm without any issues.
Notes:
- Of course, the script /etc/cron.daily/redundant has to be executable.
- To stop it from running, you can simply remove the execute bit, eg: "# chmod -x /etc/cron.daily/redundant"
- You have to pipe the command to at, using the echo statement as shown. Any command you want to run should go in between the quote marks.
- You can change the time to whatever you like. It'll be scheduled at 4:40am when cron runs the scripts under /etc/cron.daily/. You can verify that the job has been scheduled with "atq".
Does anyone know of any existing problems with the standard Slackware 15
crond and cron?
No major problems at all, but FWIW; it needs to use 'mktemp' as apparently /tmp or tmpfs is not good enough.
Got rid of it last year because of that small issue, I usually don't want random programs make tempdirs on my systems for security reasons.
Nope. It's been bulletproof here... running 24x7 without any issues at all since 15.0 was released.
I agree that cron works great in Slackware 15 and earlier versions of Slackware.
Quote:
Originally Posted by rkelsen
For things which I want to run at specific times, I use "at," which is running by default on a full/default installation of Slackware.
Doing so would be possible, but I prefer to:
crontab -l > /tmp/crontab.txt
(edit the file /tmp/crontab.txt, add what you want to do at specific times)
crontab /tmp/crontab.txt
See the man page of crontab for the syntax of the file. The above can be done both for root and for normal users. Instead of saving the crontab contents to a temporary file you might want to save it on some persistent, backed up storage to easily be able to recreate it on another installation.
Involving both cron and at in the scheduling of the same job seems both redundant and fragile to me, but each to his own.
If you don't want to edit crontabs then why not just stick a script in cron.hourly/ that checks the hour is 18 before doing anything? Seems far less involved than getting 'at' in the picture.
Back on topic:
Not encountered any issues with crond on slackware 15.0.
at-3.2.4 was broken, but Pat backed that one out.
at-3.2.5 is "fixed" but I don't like how the developer fixed it (which I've talked about in another thread).
Involving both cron and at in the scheduling of the same job seems both redundant and fragile to me,
It's not fragile at all. As I said, it hasn't missed a beat in almost 18 months of 24x7 operation. Simply leveraging the at daemon which is installed and running by default on a stock installation of Slackware.
Quote:
Originally Posted by GazL
If you don't want to edit crontabs then why not just stick a script in cron.hourly/ that checks the hour is 18 before doing anything? Seems far less involved than getting 'at' in the picture.
Involved? It's a one liner... Which you can drop in, package, and turn on and off at will. It also gives the flexibility to choose the exact minute you want the command to run.
Your proposed idea is not bad, but runs every hour instead of once per day, doesn't allow you to easily choose the exact minute to run a command, and requires more than a simple one liner. I'm not a programmer and so I struggle with regex.
By "fragility" I mean that with your approach there are a number of scenarios where downtime could result in your job not being run, being scheduled twice for the same date/time, or being run at the wrong time.
If you're happy that your box will be up 24/7 and these risks don't concern you, then that's fine, but this approach is inherently fragile and one would be better off just adding a 18:00 cron entry.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
