On Tue, 03.02.15 18:01, Martin Pitt (martin.p...@ubuntu.com) wrote: > Lennart Poettering [2015-02-03 17:29 +0100]: > > Hmm, why precisely does this stall for 90s? > > The current transaction has final.target and all other jobs which need > to be shut down. One of these now trigger "systemctl reload > postfix.service", but that reload isn't going to actually run in the > same transaction but in the next one. OTOH systemctl reload > waits for the reloading to finish, thus we have a deadlock. > > > Isn't this a case where people should just use "--no-block"? > > Kind of. Not using this is the right thing while the machine is > running, so that the reload is actually done after calling systemctl > reload, and you can go on using postfix or whatever. --no-block should > help during shutdown, or early boot (same principal bug, but slightly > different patch, see http://bugs.debian.org/624599). > > So every time you call reload you'd have to check whether or not you > are in early boot/during shutdown, or in the running system, and > conditionally use --no-block. However, as such scripts should never > call systemctl directly, but "service foo reload" (to work with other > init systems or chroot), it would be also possible to move that check > there, and conditionally add --no-block. It would just be another > thing that every distro has to re-discover :-)
I am very strongly against adding hacky work-arounds like this to PID 1. The deadlocks are deadlocks, and implying --no-block if we are in shutdown mode is a pretty drastic hack I think that special cases one peculiar case way too much. My recommendation would be to stick this into your /usr/bin/service compat glue. Use the state string "systemctl is-system-running" outputs to check if you are shutting down. If so, add --no-block to the params you pass to systemctl. Another option might be to pass --job-mode=ignore-dependencies instead of --no-block, which was created for usecases like this, even though it is frickin' ugly... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel