Is it possible to query systemd target?

[Stefan Bader]

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
> 
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20160114/b37d9968/attachment.pgp>