-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCgAGBQJWloQAAAoJEOhnXe7L7s6jPCYQAN0HLzRwQAUZlJ6hL6U5Sb8l
TE16K/NhMXbOdO4T+Vx+sxI6CXyytOAYINTXsJYl/t2cvlMzBTawbPaS57D04Db2
wVA6gZ7lVRKE+MkYu2z9Gw2M0xpo3rMIG0Ycrft8tRnGYD2zxrHYxGrlIyhaUiMa
5LjbgkOXsByIZPI3UxFBP6YEDs1I2IwD9Pjh/gCaqEas5kclnr7ziHCZjbyha3Pf
BL9tTiJ/15gApmZ6u6EVzVaBoe5nTEVij3ty1Z+Bnav0+uVjkrBbt87Fb4Shr4Kf
0Xt+cvNFAf7GLPGH+IyV84lpLRCbXdJXLW8vRu/XptaPShZW2smtU7TcGn4fdXwm
b6+RsF2AcybrBGNXY+L1DehL8B4idwWY8G1+PfVXH6c6ZwbWa/xmqJMFDAPM21HD
8Znk0QjKaoFKJuVL6VMaGhj3kQEjWENiILJtyyPS3PPN0HucubrDnHRTOrrDTTnf
1CzfKIGZ6FrzBktqinjgL/RO/qF01/k6HElWsFrx4GOa7m1MetD/IXyZtru37nYA
z4/TG4AEWHO7Hbd0f2uVbHrn5clrG7Jtd2NSwVEVX0+0Zld4SvAbt/mGDyXBzyH5
FDZUL80OyC42aPn5AnIEcA+kLWGxGF5AeDm3Bc3O6/UxFaZT+CxiY4Kk5wADYPfU
oZDASR9cWbaKv+SaJDER
=9ewR
-----END PGP SIGNATURE-----
On 13.01.2016 17:55, Martin Pitt wrote:
> Hey Stefan,
>
> Stefan Bader [2016-01-13 16:10 +0100]:
>> TL;DR
>> Is it possible to know from a script called via a systemd.service whether a stop
>> action was manually triggered (systemctl) or as part of shutdown/reboot or poweroff?
>
> This is a really slippery slope, and sounds like a big race condition.
> IMHO, if someone or something stops a unit, it should stop. But we can
> arrange for a unit to not get stopped during shutdown, which is IMO a
> cleaner approach to this problem.
Unfortunately the other way round (see below).
>
>> Right now (at least Wily+Xenial) there is a non fatal but annoying problem with
>> Xen. On shutdown/reboot systemd tries to unmount several file systems. One of
>> which is /proc/xen. Right now Xen still uses /etc/init.d/xen for start/stop. The
>> same script is also called via invoke-rc.d from *.prerm/*.postinst (which might
>> be another place to modernize at some point). And because of that there is one
>> daemon (xenstored) that must be kept running on stop (otherwise state info on
>> guests running during the upgrade is lost).
>
> I'm a bit lost here -- what does the xen init.d script have to do with
> cleaning up mounts during shutdown? When you say "systemd tries to
> unmount several file systems", that's happening very late after every
> service has stopped and it basically does the equivalent of "umount -a",
> right? (This is "umount.target", see man systemd.special.)
Right so something (likely the umount.target) does the umount late on shutdown
after all services stopped. xen currently is not a service but sysV script. It
was called but does not stop that one daemon (because the same script is called
on pkg upgrade). And because the daemon keeps the mount busy umount -a fails.
>
> Or do you mean that the xen init script does the umount, but
> has some heuristics to know whether it's during shutdown or during a
> manual "stop"?
>
>> And since xenstored keeps the /proc/xen mount busy there is always a
>> failed unmount on shutdown/reboot. Harmless but not pretty. So I
>> wondered whether I might be able to improve this for Xenial.
>
> This should be possible to do with providing an explicit (instead of
> autogenerated) /lib/systemd/system/proc-xen.mount unit which does not
> do the default "Conflicts=umount.target". This should then keep the
> mount alive all the time. I'll try this tomorrow morning (sorry, need
> to run now). But let's first clarify what you need here.
Right now I quickly hacked the init.d script to stop xenstored when "systemctl
is-system-running" returns anything else than running. This seems to be doing
what I need. If that is an acceptable way of doing this.
-Stefan
>
> Thanks,
>
> Martin
>
