Re: Cron, anacron, cronie, systemd-timers
On Sun, 07 Jul 2019 at 17:00:53 +0200, Marc Haber wrote:
> And on the third side, we have systemd timers, which are not suited as
> a complete replacement. There is code to transform crontab entries into
> systemd timer units, but functionality that cron delivers, such as
> in-sequence execution of the cron.{daily|weekly|monthly} jobs and the
> ability to send cron-job output per e-mail (which can be a nuisance, but
> is still functionality a lot of code depends upon).
Presumably you got distracted by the parenthesized clauses and lost the
end of this sentence, which was meant to end with "functionality that
cron delivers ... is lost"?
> in-sequence execution of the cron.{daily|weekly|monthly} jobs
As noted in another thread, this isn't actually missing from systemd-cron,
which still uses run-parts for these (although
https://github.com/systemd-cron/systemd-cron/issues/47 requests the
behaviour that it seems we both assumed it already had).
> ability to send cron-job output per e-mail
I think sending cron job output by email can be either a positive or a
negative, depending on the system it's happening on. On a traditional
Unix server with a local MTA and monitored local email accounts, it's
certainly expected functionality, and perhaps the best way to contact a
sysadmin - but not every Debian system falls into that category any more,
with many desktop systems having personal email travel directly between
the user's MUA and remote IMAP/SMTP servers like GMail, the same way it
typicaly would on Windows or macOS. On such systems, if there is a local
MTA at all, it will often deliver system-level email to a mbox that the
user probably isn't aware of and certainly never reads.
It has been a recurring issue that there is no good way to notify the
user of a typical desktop/laptop system about things going wrong during
boot, package installation or normal operation. The system log (syslog or
systemd Journal) is certainly imperfect, but it seems closer to a solution
than email does - it already a concept of priority, has configurable
data retention, interleaves messages from concurrent events in multiple
daemons, records segfaults (and other core dumps if systemd-coredump
is used), and includes at least a subset of messages from system boot
and daemons (admittedly rather less complete on sysvinit systems, where
each daemon has to implement syslog support for itself rather than just
logging to stdout/stderr).
smcv
Reply to: