<div>Hi Shuang,</div><div><br></div><div>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:</div><div>* stop - executing ExecStop= statements</div><div>* stop-sigterm - sending these control processes sigterm</div><div>* stop-terminate - sending these control processes sigkill, cleaning them up.</div><div>* 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)</div><div>* stop-final-sigterm, stop-final-sigkill - same as above, but for ExecStartPost= control process.</div><div><br></div><div>This means while deactivating your service is in one of the following substates, you can query this through systemctl status or D-Bus.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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: <a href="https://github.com/systemd/systemd/issues/11305">https://github.com/systemd/systemd/issues/11305</a>. 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.</div><div><br></div>On Wednesday, January 9, 2019, Liu, Shuang (ADITG/ESM) <<a href="mailto:sliu@de.adit-jv.com">sliu@de.adit-jv.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Can someone give me some advice? Thanks.<br>
<br>
Shuang Liu<br>
<br>
-----Original Message-----<br>
<br>
Hi,<br>
<br>
What happens if a wanted service in status deactivating (stop)?<br>
<br>
For example, in the service A an ExecStop= is defined and takes 0.5s.<br>
Then what should happen if a service B is started and A is WantedBy B during the 0.5s.<br>
<br>
Concrete scenario is:<br>
A USB device has defined the udev rule SYSTEMD_WANTS=A.service and is bind to B.device.<br>
It works normally as expected:<br>
        When connect the device, the A.service is started.<br>
        When disconnect, the A.service is stopped.<br>
<br>
However, if quick disconnect/connect the device (<0.5s), A.service stay in stopped and will not be restarted.<br>
Probably when connecting, the service is in deactivating and the Wants will be hence ignored.<br>
<br>
Best regards<br>
<br>
Shuang Liu<br>
______________________________<wbr>_________________<br>
systemd-devel mailing list<br>
<a href="mailto:systemd-devel@lists.freedesktop.org">systemd-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/systemd-devel</a><br>
</blockquote>