Stefan Bader [2016-01-13 18:06 +0100]:
> 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.
Which is still a .service, just an autogenerated one from the SysV
script. But in terms of dependencies, ordering, shutdown behaviour
etc. that doesn't make much difference.
> 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.
Ah, I initially thought it was deliberate that the daemon survives all
the way through shutdown. So that is not the goal, but the bug?
I still don't understand the problem here -- on a package upgrade the
sysv script gets called with "restart", or "stop" and "start" (that
depends on the dh_installinit arguments), so it should continue to run
after a package/dist upgrade. OTOH, on shutdown it gets called with
"stop". So is the init script broken to not actually stop the daemon
> 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.
I still don't understand the problem, but this really doesn't sound
like a good solution :-/ You at least need to do that if the state is
"degraded", and presumably have the same/a similar problem when this
happens under upstart (which is a valid scenario with a trusty →
Why should the init script not stop xenstored always when it's called
with "stop"? Does it DTRT with "restart"? Is the problem that trusty's
prerm does the wrong thing and we can't retroactively fix that?
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)