[systemd-devel] why don't "/usr/bin/systemd-run -t" finish within a cronjob anymore?

[Lennart Poettering]

On So, 07.10.18 00:26, Reindl Harald (h.reindl at thelounge.net) wrote:

> Fedora 28:
> 
> 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/local/scripts/webalizer.sh
> 
> last line of the script:
> /usr/bin/echo "$MY_DATE $MY_TIME  Statistiken abgeschlossen." >>
> /Volumes/dune/www-servers/_logs/usages.log
> 
> last line of the logfile:
> 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
> system mails
> 
> 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

-- 
Lennart Poettering, Red Hat