[systemd-devel] Start and stop requests for a service

[Umut Tezduyar]

On Tue, Oct 1, 2013 at 3:51 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Fri, 27.09.13 11:37, Umut Tezduyar (umut at tezduyar.com) wrote:
>
>> Hi,
>>
>> I have noticed that ExecStop is not being run on following service
>> with following requests:
>>
>> [Service]
>> Type=oneshot
>> RemainAfterExit=yes
>> ExecStart=/bin/sh -c "sleep 20 && /usr/bin/systemd-cat echo ExecStart.."
>> ExecStop=/bin/sh -c "/usr/bin/systemd-cat echo ExecStop.."
>>
>>
>> $> systemctl start hello.service &
>> $> systemctl stop hello.service
>>
>> I have couple discussions:
>>
>> 1) When a "oneshot" service is being in activating state, why doesn't
>> "stop" request wait for the service to become "active"? I would expect
>> systemd to queue "stop" request as long as service is in "activating"
>> state. I think this kind of behavior is fine for Type=simple but not
>> for Type=oneshot. KillMode=none is the only way to provide atomicity.
>
> Well, the thinking was that people would be annoyed if "systemctl start"
> hangs and they C-c it, and then do "systemctl stop" this hangs too...

Umut: Can it not be solved by something like "systemctl -f stop" to force it?

>
> In the case of Type=oneshot I think people would be particularly annoyed
> if it wouldn't act immediately, after all Type=oneshot is the kind of
> service where *all* interesting bits only happen during "activating"
> state...
>
> Not following regarding the atomicity?

Umut: At which point ExecStart= script will be interrupted is totally
dependent on when does "systemctl stop xyz" comes. If you want to
provide some transaction support (all or nothing) on the script, I
guess, you have to trap on all signals (or KillMode=none) thinking the
execution might be interrupted at any moment.

>
>> 2) If I have an "ExecStop" directive, I would expect it to run no
>> matter what. My solution is moving ExecStop to ExecStopPost.
>
> The idea was that ExecStop= is the clean way down, and ExecStopPost= the
> last resort thing to clean things up...
>
>> My use case: I have a service which sets up ip filters on ExecStart
>> and removes the filters on ExecStop. Setting up ip filters is done by
>> a script. I have ended up finding my target in an inacceptable state
>> due to "start" "stop" request coming right after each other.
>
> Hmm, so, but using ExecStopPost= should fix the issue for you, no?

Umut: Yes, ExecStopPost= has solved the problem but maybe we should
document that ExecStop= might not be executed depending on "active" or
"activating" status of an onshot.

>
> I think I don't fully get the problem, can you elaborate?
>
> There are three options basically, what to do if we get a stop request
> while we are starting something:
>
> a) wait until start finished, then immediately stop. -- I think this
>    would be a bad idea, as pointed out above
>
> b) immediately go to ExecStop= if there is. -- I think this would be a
>    bad idea, since ExecStop='s job is to do a clean shutdown, and
>    something that has not started up fully is unlikely to shutdown
>    cleanly.
>
> c) immediately go to SIGTERM/ExecStopPost=. Which seems to be the most
>    reliable choice and is what is currently implemented.
>
> Can you may a good case why a) or b) would actually be the better choice?

Umut: I don't have the perfect use case other than transaction support
I have mentioned needs to be implemented in the script which is what I
did.

>
> Lennart
>
> --
> Lennart Poettering - Red Hat, Inc.

Umut: Thanks for your input.