On Tue, Oct 1, 2013 at 3:51 AM, Lennart Poettering <[email protected]> wrote: > On Fri, 27.09.13 11:37, Umut Tezduyar ([email protected]) 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
