That would be most welcome for running dcron in a docker container. Then there'd no need to set up mail, and docker logs could be used to inspect what's going on.

If job Y is waiting on job X (AFTER=X) but job X (ID=X) does not generate a cronstamp (because it's not scheduled via FREQ, but via the "classic" fields), then job Y is never executed.

This is undocumented behaviour (and IMHO counter-intuitive). All jobs named with an ID should probably generate a cronstamp, regardless of the syntax with which they are scheduled.

Compilation with gcc gives a warning here:

database.c: In function 'ReadTimestamps':
database.c:268:8: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
        if (ptr && (*ptr == 0 || *ptr == '\n'))
        ^~
database.c:271:9: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
         tm.tm_isdst = -1;
         ^~

Hi,
I have a problematic use case and before i fill a github issue, i would like to know your opinion about it.

Let's say we are the October 11 2018.
I have cron jobs scheduled "@hourly" and "@daily" and everything is correct.

I manually change my system date and i set it to January 01 2000.
I have the impression that my jobs will never be run until October 2018 (18 years to wait).
I expect my job to be scheduled one hour or one day after their last run or at least one hour one day after my date change
but not 18 year.

I would like to known what kind of workaround we can do to handle this use case.

In main.c you handle "big" delta as :

if (dt < -60*60 || dt > 60*60) {
	t1 = t2;
	printlogf(LOG_NOTICE,"time disparity of %d minutes detected\n", dt / 60);
}

Maybe we can add something to fix cl_LastRan + timestamp file, cl_NotUntil values in this block.

What do you think about this idea ?
Do you have any other idea to handle system date changes in order to keep @xxxx jobs scheduled hourly, daily, ... ?

Best regards,
Herve Codina

After merging of #3, my @daily @hourly etc jobs are not run. I've reverted back to 6186237 and they are run again.

Does anyone got any info on the status of http://www.jimpryor.net/linux/dcron.html?
At the moment it's seems to be down (and so the tarball download).
Thx

$ cat /etc/cron.d/zfs-auto-snapshot

PATH="/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin"

*/15 * * * * root which zfs-auto-snapshot > /dev/null || exit 0 ; zfs-auto-snapshot --quiet --syslog --label=frequent --keep=4 //

git clone, make, ./crond -f

./crond 4.5 dillon's cron daemon, started with loglevel notice
failed parsing crontab for user root: PATH="/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin"

root also gets an email saying "/bin/sh: 1: root: not found"

This is from a linux distro (voidlinux fyi); I don't know if the dragonflybsd convention is different,
but here at least files in /etc/cron.d are supposed to be that way (see eg http://deb.debian.org/debian/pool/main/a/anacron/anacron_2.3-27.debian.tar.xz),
ie the first field after the time specification is a username to run the command as,
and lines like "foo=bar" mean environment assignment
(the one above looks pointless to me, and I'm not sure if any other cron implementation gets confused by the quotes; I'm assuming they are ok since https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=zfs-auto-snapshot;dist=unstable doesn't say anything)

If there's any more info or anything you need please do let me know.

Hi! I switched from Arch to Void, and am now on musl, runit, dcron and rsyslog (hugs rsyslog, I missed you sooo much).

Like systemd, runit does not detach jobs. Currently, Void runs dcrond alongside 'logger -p cron.notice' because '-f' not only stops detaching, it also turns off syslog.

Would you accept a patch for '-S' to keep syslog on, to allow it to override the no-syslog part of '-f'?

Thanks for reading!

-p

I'm trying to have a job run every 2nd and 4th Sunday of a month. I've tried both
33 8 2,4 * 0 /path/to/commmand
and
33 8 2,4 * sun /path/to/command
syntaxes and neither of these runs the job at all. The "every week" syntax (33 8 * * 0) works just fine.

I suggest changing $SCRIPT || echo "$SCRIPT" failed into, say
$SCRIPT || echo "$SCRIPT" failed 1>&2.

Motivation: most cron strings ignore standard output.

Add option to use nano instead of vi for editor.

I'd like to understand why this implementation of crontab is designed to exit zero when asking to list a crontab for a user that doesn't have a spool file. To me, it makes sense to exit non-zero in this instance. It would be great if crontab did this.

Not saying this project needs to follow suit, but cronie exits nonzero under the same conditions. Cronie is the default in CentOS and RHEL.

My particular use case is that I'm writing a shell script that backs up a user's current crontab to a file and deletes it:

if crontab -l -u www-data >/tmp/www-data.crontab.bak; then
    mv -i /tmp/www-data.crontab.bak .
    crontab -d -u www-data
fi

(I know could of course pipe the output to wc -l.)

Using s6-rc, dcron dies because setpgid(0,0) fails.

My s6-rc/dcron/ directory has the following structure

$ ls
dependencies
pipeline-name
producer-for
run
type
$ cat ./producer-for
dcron-log
$ cat ./pipeline-name
dcron-pipeline
$ cat ./dependencies
fsck
$ cat ./type
longrun
$ cat ./run
#!/bin/execlineb -P
fdmove -c 2 1
exec -c
/usr/sbin/crond -M /bin/true -f

Running s6-rc -u change dcron results in dcron-log capturing the
following:

setpgid: Operation not permitted

However, running sudo /usr/sbin/crond -M /bin/true -f in a TTY works
just fine. After discussion with the s6 folks, it appears this is because
s6 makes the service it supervises the session and group leader, and
indeed setpgid(2) will fail with EPERM if the process is currently a
session leader.

I'm not very familiar with why the details behind dcron creating a new
group, but from the comments, it looks like EPERM isn't necessarily
an error condition, since dcron is already in the state it wants to
change to. Replacing the relevant code (around main.c:272) with

if (getsid(0) != getpid()) {
        if (setpgid(0,0)) {
                perror("setpgid");
                exit(1);
        }
}       

might do what's desired (or perhaps getpgrp() in place of getsid(0),
depending on exactly what dcron needs?). I'm unsure enough of the inner
workings of dcron that I'm not submitting that as a pull request, however.

The C source files only state the following:

May be distributed under the GNU General Public License

However, it is not specified which version of the GPL is being used. ln addition to that it would be neat if you could add a license file containing the entire license text to the repository.

This seems like a dead project.

I have forked it and included several of the open PRs here. I plan on testing them for ~week and then tagging the new version 4.6

Not all PRs will make it, some im not clear on what they are exactly attempting to do. Please resubmit your PR on my fork: https://github.com/ptchinster/dcron

Can we get a new release, like 4.6 or 4.5.1? Fixing #3 is a major new function, and it would be nice to get it out to users who rely on their distro's packages instead of building from git sources.

Hi,

if a job returns code 11, it should be scheduled again, but isn't (in my setup).
A simple script to test this is:

!/bin/bash

bit=$(bc <<< "(($(date +%s)+30)/60)%2")
echo -n "${bit}: " >> /tmp/logfile
date >> /tmp/logfile
[ ${bit} -eq 0 ] && exit 11
exit 0

and then add "*/2 * * * * ID=test /path/to/toggle" to your crontab.

The script should be run each minute:

• at even minutes due to direct call from dcron and
• odd minutes due to "exit 11" during even minutes.
  However, it's only run at even minutes.

I'm runing crux (crux.nu) and installed dcron from source: http://www.jimpryor.net/linux/releases/dcron-4.5.tar.gz

cheers,
deepthought

Hi Jim,
I've hunted down a problem that was an issue at my systems for more than a year now.
I run all my systems with NFS root, but only some systems put their /tmp on tmpfs or a local drive.

Since the last big system update about a year ago, where also dcron was replaced with a newer version, some systems did'nt send email from cron jobs any more. Today I inspected this problem and could show, that the problem occurs on my systems only, if the /tmp is on NFS.

My systems run Gentoo, the package I am testing with is dcron-4.5-r1, which contains dillon's cron daemon 4.5, kernel is 4.11 with aufs patch, email system ist postfix.

Symptoms are:

• cron jobs run fine and in time
• stderr and stdout is collected in temporary file (I could see this)
• when job is finished, email handler is not invoked (sendmail call is not seen, with supplied email handler -M switch also no invocation seen), thus no email is sent

Please feel free, to ask more questions about runtime environment or more tests.

Best regards, JLO

This line in crontab

*/1 * * * * printf 'To: someuser\nSubject: spam\n' > /dev/stderr

results in the following behaviour:

• For root, the spam is sent, verbatim, to someuser
  (and of course, if the printf()-ed string is changed to something
  that does not fit the format of an email, the MTA will probably refuse to send it).
• For non-root user, an error message will occur saying
  /bin/sh: /dev/stderr: Permission denied.

While one expects that:

• To the user that the crontab belongs to (or whoever it finally redirects to via mail aliases),
  a message is sent back, with the printf()-ed string as the mail body.