On 13.01.2016 23:07, Martin Pitt wrote: > Hey Stefan, > > 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 > on "stop"?
The way we inherit things from Debian things are a bit more legacy. So the init script is called with "stop" in a *.prerm script and started with "start" in a *.postinst one. So there is no difference between the stop on upgrade and the stop on shutdown. Steve had a good idea there about splitting the scripts. But while thinking more about the whole thing I am wondering whether some partial fault is in the stop action of the mountall.target. Traditionally I believe, only filesystems mounted by mountall got unmounted. Which should be those in /etc/fstab (except /). So why is /proc/xen attempted? Its mounted by the xen init.d script, not via fstab. So I am going back and forth wondering whether unmounting /proc/xen should be fixed or the stop of xen. On one side its cleaner to undo anything done on start but that also slows down the process. There probably is a policy for that but from a feeling the deciding question would be whether omitting a step prevents / from getting cleanly deactivated (or synced and switched to ro). There did not seem to be an issue with not stopping xenstored on shutdown in the past. Still it could be a cleaner approach to split things into two and have one not restarted on upgrade. -Stefan > >> 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 → > xenial dist-upgrade)? > > 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? > > Thanks, > > Martin > > >
signature.asc
Description: OpenPGP digital signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
