F20 System Wide Change: No Default Sendmail

Thu Jul 25 00:13:33 UTC 2013

On Wednesday 24 July 2013 13:23:08 Lennart Poettering wrote:
> On Tue, 23.07.13 04:03, Oron Peled (oron at actcom.co.il) wrote:
> > There are two issues however:
> >  * The log-splitting of journald is really nice feature. But it doesn't
> >    work for cron:
> >         $ echo '* * * * * /bin/echo "Test output from cron"' | \
> >         
> >              crontab '-'    # than wait a minute
> >         
> >         $ journalctl        # only shows crontab, not the cron output
> >         $ su -
> >         # journalctl        # Cron output is properly shown.
> 
> Also as mentioned on this thread, this doesn't work for cron right now
> as cron actually collects all log output of a job and then posts it
> under its own identity, which is why it is attributed to cron/root.

Sounds reasonable, but please look at the result of previous tests:
   # journalctl SYSLOG_IDENTIFIER=CROND --output verbose
   Tue 2013-07-23 03:31:01 IDT ...
        PRIORITY=6
        _UID=0
        _MACHINE_ID=...
        _HOSTNAME=...
        _EXE=/usr/bin/bash
        _TRANSPORT=syslog
        SYSLOG_FACILITY=9
        _SELINUX_CONTEXT=system_u:system_r:crond_t:s0-s0:c0.c1023
        _GID=501
        _AUDIT_LOGINUID=501
        _SYSTEMD_OWNER_UID=501
        _BOOT_ID=...
        SYSLOG_IDENTIFIER=CROND
        _COMM=sh
        MESSAGE=(oron) CMD (/bin/echo "Test output from cron")
        _CMDLINE=/bin/sh -c /bin/echo "Test output from cron"
        SYSLOG_PID=19788
        _PID=19788
        _AUDIT_SESSION=194
        _SYSTEMD_CGROUP=/user/501.user/194.session
        _SYSTEMD_SESSION=194
        _SOURCE_REALTIME_TIMESTAMP=1374539461144186

It seems it was filtered by _UID, but what's the difference between that
and _AUDIT_LOGINUID and _SYSTEMD_OWNER_UID?

> THis is, if you so will, a misdesign in cronie.

Maybe:
 * But if it writes to syslog as root (_UID=0), how come _AUDIT_LOGINUID
   is my uid?
 * This "missdesign" cannot exist in the mail interface, since any sane MTA
   delivers local mails as the recipient user.

In any case, this latent bug is triggered by removal of MTA -- so solving
it would drop at least this show-stopper for the suggested feature.

> >  * Logs are inherently line-oriented (which is very good for their
> >    intended use case). However, many cron-jobs produce various reports
> >    which are multi-line in their nature -- not a very good fit.
> 
> Cron currently collects all the job's logs in one go and then writes
> them under its own identity in one big transaction out. THis means that
> there's no way to get "live" access to the logs of current long-running
> jobs. Which is certainly suboptimal.

Hmmm... you are right that for *some* cron-jobs, logging is better fit
than mailing. However, for *others* it's the reverse. The examples
I gave are reports (e.g: think about HTML report -- is there any
sense in <div...> line without its matching </div>?)

There are obviously orders of magnitude of the "report" case cron-jobs
then the prior -- just due to the fact the default "cron-to-mail"
existed from early 80's on very wide OS range and the "cron-to-log"
is relatively new feature that few heard about (I only heard about
it in this thread -- thanks).

The default mentioned in this thread -- mail and fall back to logging
if there's no MTA sound very reasonable design to me. It would be
*nice-to-have* if there was a way to specify "cron-to-log" per-job
(or even per-crontab) without resorting to "| logger...", but
that's for another mail-thread :-)

> Note that due to the context we collect of messages it should be
> preferable these days if logging happens immediately per-line and then
> is recombined at display time, rather than collected and done at the
> end, simply to make sure latencies are low, and you get a live view into
> the system.
> But either way, both philosophies (log individual log lines immediately
> + log them all in one) work fine with journald, we can do
> both, better than syslog ever could.

Obviously, journald manage its log data better than syslogd.

However, we compare *logging* in general against *mail*:
 * Mail is "pushed" to the user, while the user need to actively read ("pull")
   the log. So mail, by definition is a kind of "notification-system".

 * Unlike desktop notifications which are normally transient, mail can be
   read offline, sorted by arbitrary user criteria ("this mail is
   important *to me* so I put it in that folder"), is normally saved
   long-term (and usually backed-up), can be trivially be forwarded
   (automatically/manually), shared between systems etc.

 * Logging shares most previously mentioned mail attributes (as compared
   to desktop notifications) -- i.e: it's persistent, may be backed-up, may
   be routed. However, it's line-oriented and not message oriented.

 * Obviously, messages may be re-constructed from lines, just like messages
   may be constructed from byte-streams -- do you use SOCK_STREAM for
   SOCK_DGRAM use-cases? (let's talk local-sockets, so we don't drift
   to reliability/ordering issues which are not relevant to my analogy)

I don't bitch on journald because "it-is-not-good-as-an-MTA-replacement":
 * I say a *very* common case for cron is *reports*
 * In these cases mail has many advantages: message-based, pushed, archived
   by user criteria ([subjective] urgency, responsible party, etc.),
   view on any platform/OS (e.g: your smart-phone).
 * It would be nice if we could adapt for other classes of jobs you
   described, where logging is more suitable -- but not by killing
   the more common use-cases (at least currently).

And again, if the feature talked about removing MTA from minimal I would
not have any problem (think chrooted environments, containers, customized
thin VM provisioning, etc.) -- but not from *default* desktops/servers.

Bye,

-- 
Oron Peled                                 Voice: +972-4-8228492
oron at actcom.co.il                  http://users.actcom.co.il/~oron
"write your own operating system.  It has worked every time for me"
           -- Linus Thorvalds
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130725/7285efc2/attachment.html>