On Fri, 27.09.13 11:37, Umut Tezduyar (u...@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... 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? > 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? 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? Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel