[systemd-devel] generator logging during daemon-reload

[Alexandre Detiste]

Le lundi 10 novembre 2014, 14:32:49 Lennart Poettering a écrit :
> > I know that generators should log to /dev/kmsg during early boot.
> 
> Correct!

Yes, but then the log appears as a ugly big chunck without the timestamp & host on the left; 
except the first line. Is it ok to reopen /dev/ksmg for each line writen to avoid this ?

Google gave me this:
http://unix.stackexchange.com/questions/35639/how-can-i-write-to-dmesg-from-command-line

With take me back here :-) ! which is easy to understand.
http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journald-kmsg.c

> (...) deadlocks (...)
Ok, I indeed got some while doing tests for my /var/spool/cron/crontabs problem.

I finally settled to generate a kind of 'transient' service that does a "daemon-reload ; restart cront.target" _only_ 
if this path doesn't exist; and it iself contains a "ConditionDirectoryNotEmpty=/var/spool/cron/crontabs"
to avoid needless daemon-reload.

The twist: on the second run of the generator, this path now _does_ exist; 
so this service doesn't generate itself again.
At first, I had used 'ExecStartPost=' for the "restart part" ; 
but the .service simply vanish during the daemon-reload and can never finish.
(this behaves like a self-modifying shell script)

Now I do this, it turns the ExecStart in a kind of "atomic" operation:

  ExecStart=/bin/sh -c "/bin/systemctl daemon-reload ; /bin/systemctl try-restart cron.target"

https://github.com/systemd-cron/systemd-cron/blob/master/src/bin/systemd-crontab-generator#L471

> Generators really really shouldn't talk to any other services, and
> this means for logging they should log to /dev/kmsg or suchlike.

So we should also avoid sending mail with /usr/sbin/sendmail , for example ?

Thanks,

Alexandre Detiste