Would be great to have systemd-cron ("systemd units to run cron scripts", rendering a dedicated cron daemon obsolete) in Gentoo. The Gentoo Wiki page on systemd advertises it [1] and there exists an ebuild in an overlay [2]. [1] https://wiki.gentoo.org/wiki/Systemd#Replacing_cron [2] http://gpo.zugaina.org/sys-process/systemd-cron
I think it is a great idea, but one gap I see here is user crontabs. As far as I can tell this software only takes care of the cron.* directories. At least it didn't seem to handle an fcron-format user crontab copied to /var/spool/cron/user (and the fact that it doesn't handle existing fcron crontabs is at least worth a note). Could use docs in general. Oh, one other issue - the ebuild installs a cron-update.service that looks for /bin/systemctl - the Gentoo path is /usr/bin/systemctl.
(In reply to Richard Freeman from comment #1) > Oh, one other issue - the ebuild installs a cron-update.service that looks > for /bin/systemctl - the Gentoo path is /usr/bin/systemctl. Note to self: sed this path based on ROOTPREFIX.
> Oh, one other issue - the ebuild installs a cron-update.service > that looks for /bin/systemctl - the Gentoo path is /usr/bin/systemctl. I've fixed it in the build. I guess Arch users will appreciate this too. https://github.com/systemd-cron/systemd-cron/commit/42251952580e6019be780900e6ac9902a9bc0f6c "/bin/sh" remains, I guess it is a compat link (never used Gentoo or Arch) > As far as I can tell this software only takes care of the cron.* directories. It reads /etc/cron.d/* , /etc/anacrontab , /etc/crontab/ , /etc/cron.daily|weekly etc... & /var/spool/<whatever>/crontabs/* . It justs can't _write_ user crontabs because a python script can't be setuid. I don't know about Fcron; I'll have a look at it for ideas.
(In reply to Alexandre Detiste from comment #3) > > As far as I can tell this software only takes care of the cron.* directories. > > It reads /etc/cron.d/* , /etc/anacrontab , /etc/crontab/ , > /etc/cron.daily|weekly etc... & /var/spool/<whatever>/crontabs/* . > > It justs can't _write_ user crontabs because a python script can't be setuid. > > I don't know about Fcron; I'll have a look at it for ideas. Fcron does things differently - I believe its crontabs are in binary format as well. Migrating to a conventional user crontab isn't the end of the world.
TL;DR: if you need a specific feature; add it to our bugtraquer: https://github.com/systemd-cron/systemd-cron/issues ------ Ok I have now read about Fcron. The most interresting new feature versus Vixie cron is the "persistent" timers. systemd-cron also implement those directly upon systemd's "Persistent=true" feature. There are subtle difference , but most users wouldn't care. See: https://github.com/systemd-cron/systemd-cron/blob/master/src/man/anacrontab.5.in#L61 systemd-cron let also systemd do all the hard work. systemd saves all the timestamps in /var/lib/systemd/timers/stamp-<unit-name>.timer . But all other fancy '%&@' options are currenlty not supported; and systemd-cron will remain both way compatible with vixie-cron, it uses environement keypairs KEY=VALUE that are ignored by vixie-cron for its configuration. --- I guess if you'd like to migrate the crontabs, something like # for <each user>; # do fcrontab -l -u $user | crontab -u $user # done ...with a bit more error checking would fit the bill, as long as no fancy options have been used.
sys-process/systemd-cron-1.5.3 was added to portage. However, it downloads the source tarball under a very generic name, which I believe is not advisable: `v1.5.3.tar.gz`. I believe the `SRC_URI` `->` operator should be used to rename the file to `${P}.tar.gz`.
(In reply to Dennis Schridde from comment #6) > sys-process/systemd-cron-1.5.3 was added to portage. However, it downloads > the source tarball under a very generic name, which I believe is not > advisable: `v1.5.3.tar.gz`. I believe the `SRC_URI` `->` operator should be > used to rename the file to `${P}.tar.gz`. Good catch - agree 100%. I'll take care of that when I get a chance (but I'm out a few days so I'll wait until the end of the week).
Thanks for adding it to the tree! One thing, though: shouldn't it be added to virtual/cron, or is there a reason for not doing that?
A problem here running crontab-systemd as regular user. I have USE=setuid set. Without USE=setuid it throws a python exception (permission error on /var/spool/cron). $ crontab-systemd 5 * * * * /bin/echo hello <Ctrl-D> Cannot open output file: Bad file descriptor I have tried adding my user to /etc/cron.allow as "man crontab-systemd" tells but no luck.
By the way, I didn't understand how those cron permissions work: if cron.deny takes priority over cron.allow and if "cron" group membership means anything.
Also, maybe it's good to symlink /usr/bin/crontab-systemd to /usr/bin/crontab so that KDE's scheduling applet (in System Settings) or similar software could call this crontab script to update user's crontab.
sys-process/systemd-cron-1.5.3 is in the tree.
