some cron jobs not "firing"

Make sure your scripts have execute permission, and also that they have something like:

#!/bin/bash

as the first line of the script (this of course assumes you're using a bash script - if it's perl, that should be #!/usr/bin/perl instead).

@hernan43:

Anyway, I am used to just dropping scripts in these directories and having them run.
Well… As far as I've heard it is discouraged to add and tamper with the files in these directories unless you really know what you are doing. Supposedly the Debian package manager may do things here from time to time, as these are the system (not user) cron jobs.

Instead, crontab is your friend and will happily come to your rescue:

root# man crontab
root# man 5 crontab       (ok, works on Gentoo, maybe not on Debian)
root# crontab -e

As far as I know, it is perfectly acceptable to add my own scripts to these directories. These scripts have nothing to do with the debian package stuff so they should be ok. They are executable and they just flat out don't run. I have done this countless times. I am boggled as to what I am doing wrong. I'll just keep hitting google.

–Ray

@hernan43:

As far as I know, it is perfectly acceptable to add my own scripts to these directories. These scripts have nothing to do with the debian package stuff so they should be ok.
Just checked this up a bit more. Seems all the files in /etc/cron.* are run by the system /etc/crontab on the times specified therein. They are executed by /bin/run-parts (at least on the Debian box I just checked).

Idea: Why not try to execute that program manually as root to see what happens? Do check "man run-parts" and "more /etc/crontab" first though, to make sure nothing explodes and to get the right command-line switches.

I can execute it fine by hand from the cron directory. The weird thing is, every script in that directory executes except the one. It has the same permissions as all of the other scripts. I even restarted cron a bunch of times. I know I am doing something wrong, I just have to nail down what it is ;).

–Ray

Yeah, but I meant:

# run-parts --test /etc/cron.daily
# run-parts --verbose /etc/cron.daily

Or is that what you tested?

Well, a couple of things. When I did the man run-parts(which I hadn't done before) I noticed that there were certain naming conventions that your script had to abide by. My script was named epylog.cron, and I changed it to just read as epylog. Then I restarted cron, and then I ran the run-parts –test. This time it showed my script in the list of things to run. Tomorrow, I will know for certain, but it looks like I just had to re-name my script. My thanks to cederberg as I had not thought to look into run-parts specifically until he had mentioned it. Thanks again.

--Ray

@hernan43:

As far as I know, it is perfectly acceptable to add my own scripts to these directories. These scripts have nothing to do with the debian package stuff so they should be ok.

The problem is that your scripts may be overwritten by a new package installation if you happen to get unlucky in your naming. Prefixing your scripts with local_ is probably a good bet. The robust way to do it is to switch on LSB compliant naming (man run-parts) and follow the rules for local names.

I do, however, tend to discourage people from using the Debian cron.* directories for local stuff. Those directories were setup so that packages would have a way to use cron without having to modify /etc/crontab and possibly lose local sysadmin edits. Therefore, the canonical Debian Way is for the local admin to use /etc/crontab.

BTW, I don't mind people submitting questions about Debian cron via the Debian BTS. It helps me identify weak points in the man pages.

On my gentoo I woud check this by running rc-update show and looking for vixie-cron.