Does cron execute jobs asynchronously

There are two lists of scheduled tasks (crontabs).

Each user (including root) has a per-user crontab which they can list with crontab -l and edit with crontab -e. The usual Linux implementation of cron stores these files in /var/spool/cron/crontabs. You shouldn't modify these files directly (run crontab -e as the user instead), but it's safe to list them to see what's inside. You need to be root to list them.

There is a system crontab as well. This one is maintained by root, and the jobs can run as any user. The system crontab consists of /etc/crontab and, on many systems, files in /etc/cron.d. These files have an additional column: after the 5 date/time fields, they have a “user” field, which is the user that the job will run as. It's common to set up /etc/crontab to run scripts from directories /etc/cron.hourly, /etc/cron.daily, etc. and that's how it's done on Raspbian.

So look in all these places: /var/spool/cron/crontabs/* (you need to be root for this one), /etc/crontab, /etc/cron.*.

You can also get information in the system logs. They won't tell you where the job was listed, but they tell you exactly what command is being executed, so you can search for the command text. For example, this is the entry that runs commands in /etc/cron.hourly every hour:

May 11 07:17:01 darkstar CRON[2480]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)

Using cron is the correct way to schedule periodic running of tasks on most Unix systems. Using a personal crontab is the most convenient way for a user to schedule their own tasks. System tasks may be scheduled by root (not using the script below!) in the system crontab, which usually has an ever so slightly different format (an extra field with a username).

Here's a simple script for you. Any user may use this to manage their own personal crontab.

• It doesn't do any type of validation of its input except that it will complain if you give it too few arguments. It is therefore completely possible to add improperly formatted crontab entries.

• The remove sub-command takes a line number and will remove what's on that line in the crontab, regardless of what that is. The number is passed, unsanitized, directly to sed.

• The crontab entry, when you add one, has to be quoted. This affects how you must handle quotes inside the crontab entry itself.

Most of those things should be relatively easy for you to fix.

#!/bin/sh

usage () {
    cat <<USAGE_END
Usage:
    $0 add "job-spec"
    $0 list
    $0 remove "job-spec-lineno"
USAGE_END
}

if [ -z "$1" ]; then
    usage >&2
    exit 1
fi

case "$1" in
    add)
        if [ -z "$2" ]; then
            usage >&2
            exit 1
        fi

        tmpfile=$(mktemp)

        crontab -l >"$tmpfile"
        printf '%s\n' "$2" >>"$tmpfile"
        crontab "$tmpfile" && rm -f "$tmpfile"
        ;;
    list)
        crontab -l | cat -n
        ;;
    remove)
        if [ -z "$2" ]; then
            usage >&2
            exit 1
        fi

        tmpfile=$(mktemp)

        crontab -l | sed -e "$2d" >"$tmpfile"
        crontab "$tmpfile" && rm -f "$tmpfile"
        ;;
    *)
        usage >&2
        exit 1
esac

Example of use:

$ ./script
Usage:
    ./script add "job-spec"
    ./script list
    ./script remove "job-spec-lineno"

$ ./script list
     1  */15 * * * * /bin/date >>"$HOME"/.fetchmail.log
     2  @hourly /usr/bin/newsyslog -r -f "$HOME/.newsyslog.conf"
     3  @reboot /usr/local/bin/fetchmail

$ ./script add "0 15 * * * echo 'hello world!'"

$ ./script list
     1  */15 * * * * /bin/date >>"$HOME"/.fetchmail.log
     2  @hourly /usr/bin/newsyslog -r -f "$HOME/.newsyslog.conf"
     3  @reboot /usr/local/bin/fetchmail
     4  0 15 * * * echo 'hello world!'

$ ./script remove 4

$ ./script list
     1  */15 * * * * /bin/date >>"$HOME"/.fetchmail.log
     2  @hourly /usr/bin/newsyslog -r -f "$HOME/.newsyslog.conf"
     3  @reboot /usr/local/bin/fetchmail