|
On Wednesday 24 July 2013 13:23:08 Lennart Poettering wrote: > On Tue, 23.07.13 04:03, Oron Peled (oron@xxxxxxxxxxxx) 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@xxxxxxxxxxxx http://users.actcom.co.il/~oron "write your own operating system. It has worked every time for me" -- Linus Thorvalds
|
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
