On Wednesday 24 July 2013 13:23:08 Lennart Poettering wrote:

> On Tue, 23.07.13 04:03, Oron Peled (oron@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@actcom.co.il http://users.actcom.co.il/~oron

"write your own operating system. It has worked every time for me"

-- Linus Thorvalds