Post by Reindl Harald
root 7902 0.0 0.0 75008 3532 ? SN 00:07 0:00
/usr/bin/systemd-run -t -p ProtectSystem=full -p ProtectHome=yes -p
PrivateDevices=yes -p PrivateTmp=yes -p NoNewPrivileges=yes --quiet
--nice=19 --uid=wwwcron --gid=apache /usr/bin/bash
/usr/bin/echo "$MY_DATE $MY_TIME Statistiken abgeschlossen." >>
07-10-2018 00:12:51 Statistiken abgeschlossen
"/usr/bin/systemd-run" is started within a root-cronjob like all the
months before - so why in the world does it never finish after upgrade
to F28 with systemd-238-9.git0e0aa59.fc28.x86_64?
and yes it's "finished" at reboot - until last night the call had
"--unit=webalizer.service" which leaded to erroes that the unit already
exists and execution was skipped - at reboot i had crap bash errors as
what in the world is going on here?
and yes there are good reasons to call "systemd-run" from a cron script...
So where precisely does it hang?
Note that "-t" called from a cronjob doesn't really make that much
sense. "-t" is used to allocate an interactive PTY for the service,
you only want to use that from an interactive shell, otherwise it's
generally more a problem of its own. That's because a PTY only knows a
bidirectional "hangup" concept, but not separate "eof" conditions for
stdin and stdout. Now, cron starts its jobs with stdin connected to
/dev/null and stdout to the log system. If you now tell nspawn to
allocate a pty and connect it to that, then this means the EOF on
stdin (because /dev/null generates a constant stream of EOFs) will
cause nspawn to issue a hangup to the PTY, which mean the service will
be quite unhappy because it is running on a hung up tty, which results
in EPIPE and whatnot when you write to it.
Because EOF and PTY hangup don't really map that nicely to each other
we had some rearrangements when this is requested in the past
releases, and the effect that some things now work better and others
work less well. Either way, don't use -t mode if you are not actually
using things interactively. What you are looking for is "--pipe" (aka
-P), which also allows you to acquire the output of the service you
invoke, but does not involve PTYs or such, but just plain pipes.
Lennart Poettering, Red Hat