[systemd-devel] Wanted service in status deactivating

[Jonathon Kowalski]

Hi Shuang,

Let's begin by answering what deactivating means for a service. systemd has
around different unit types, which encapsulate a system resource needed for
maintainence and boot up tasks. There are device units, mount units,
services, and so on. Every unit has a state of its own, and the unit object
in systemd has 5 generalized states one of these sub states of subsystem
specific units map to. Units have states called activating, active,
deactivating, inactive, and failed. For services, deactivating covers and
maps to following sub states:
* stop - executing ExecStop= statements
* stop-sigterm - sending these control processes sigterm
* stop-terminate - sending these control processes sigkill, cleaning them
up.
* stop-final - executing ExecStopPost=, unconditionally executed whenever
something in Exec*= fails or not (otherwise the one statement that fails
causes everything else below it to be skipped unless errors from it are
masked through the use of - prefixed to command)
* stop-final-sigterm, stop-final-sigkill - same as above, but for
ExecStartPost= control process.

This means while deactivating your service is in one of the following
substates, you can query this through systemctl status or D-Bus.

Coming on to Wants=, this is a weak dependency. All it does is trigger a
start job for the unit referenced and that's it. What happens with that
unit wouldn't affect our unit. It just acts as a way to trigger a start job
for the said unit whenever we start up. No other state changes causes any
effect.

You describe SYSTEMD_WANTS= property, this is a bit different. This causes
the device unit to gain a Wants= dependency on that unit, so that its start
job (which serves as a way to wait until the device is plugged) pulls the
said unit in. However, that unit is also Bound to this device unit, as you
note. This is through the BindsTo= dependency, or its opposite BoundBy=
appearing in property listing of the device unit. This causes disappearance
of the device unit any how (through systemd or not) to cause the said unit
to be stopped as well.

You describe the scenario where a quick disconnect causes the start job to
not trigger after the stop job in progress completes (because that was
triggered by removing the device). This is because the job mode used when
triggering a JOB_START job by the state machine internally uses JOB_FAIL,
which means any conflicting jobs will not be replaced and the said job will
instead be cancelled.

This is known behaviour, and a consequence of the fact that a unit cannot
have more than one job installed. This also causes problems with Restart=
if it races with stop jobs of units bound to the one restarting. See:
https://github.com/systemd/systemd/issues/11305. This is probably something
to be raised as a bug, because you actually want the start job to processed
(or in the non-ideal case, cause the start job to replace the stop job, but
that causes unclean shutdown of service). This can probably dealt like
reload jobs where they are marked as installed internally but re-run, but
the side effects of such a change (without atleast introducing some job
mode for this special purpose) are unfound.

On Wednesday, January 9, 2019, Liu, Shuang (ADITG/ESM) <sliu at de.adit-jv.com>
wrote:

> Can someone give me some advice? Thanks.
>
> Shuang Liu
>
> -----Original Message-----
>
> Hi,
>
> What happens if a wanted service in status deactivating (stop)?
>
> For example, in the service A an ExecStop= is defined and takes 0.5s.
> Then what should happen if a service B is started and A is WantedBy B
> during the 0.5s.
>
> Concrete scenario is:
> A USB device has defined the udev rule SYSTEMD_WANTS=A.service and is bind
> to B.device.
> It works normally as expected:
>         When connect the device, the A.service is started.
>         When disconnect, the A.service is stopped.
>
> However, if quick disconnect/connect the device (<0.5s), A.service stay in
> stopped and will not be restarted.
> Probably when connecting, the service is in deactivating and the Wants
> will be hence ignored.
>
> Best regards
>
> Shuang Liu
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20190110/df5a528b/attachment.html>