Discussion:
why don't "/usr/bin/systemd-run -t" finish within a cronjob anymore?
(too old to reply)
Reindl Harald
2018-10-06 22:26:55 UTC
Permalink
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...
Reindl Harald
2018-10-10 11:30:34 UTC
Permalink
no response, but please stay on-list

anyways, i removed "-t" which works fine outside cronjobs but no longer
when called from crond, in that case no problem, normally not what you
want because it don't block and follow-up commands should not get
started in many usecases

/usr/bin/systemd-run -p StandardOutput=null -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
Hi Reindl
I am interested in finding out the solution to your problem.
Have you had any results off-list perhaps because I do not see any
replies to your message.
Thank you
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/local/scripts/webalizer.sh
/usr/bin/echo "$MY_DATE $MY_TIME Statistiken abgeschlossen." >>
/Volumes/dune/www-servers/_logs/usages.log
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...
Lennart Poettering
2018-10-16 16:41:06 UTC
Permalink
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/local/scripts/webalizer.sh
/usr/bin/echo "$MY_DATE $MY_TIME Statistiken abgeschlossen." >>
/Volumes/dune/www-servers/_logs/usages.log
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
Continue reading on narkive:
Loading...