Am 17.01.19 um 06:04 schrieb Jonathon Kowalski: > On Thu, Jan 17, 2019 at 4:49 AM Christopher Cox <ccox@xxxxxxxxxxxxxx> wrote: >> Adding some extra systemd clarification. Saying do this After or Before other >> service doesn't mean the start/stop completes before moving on. It may execute >> asynchronously before/after, but processes aren't done synchronously. >> > > This isn't right. systemd's ordering is purely defined for jobs in > queue. If your start job is ordered after another unit's start job, > then it really will wait for the other start job to complete before > dispatching yours. This may produce erroneous results if you don't > configure the readiness of the service you wait on correctly, but that > isn't a systemd issue at that point. Similarly, if a stop job for it > gets enqueued, it will walk the reverse dependency and add one in > queue for yours too, and yours will become runnable before the other > one does, and as long as you're stopping, the other unit's stop job > keeps waiting on you atleast (if nobody else) in queue. to make it clear: Type=simple won't work because that implies foreground process without forking and systemd can't have any clue of the initialization state of the service perferred Type=notify which must be supported by the daemon or at least Type=forking which needs the daemon to do a proper double fork *after* it is ready to accept clietn tasks at shutdown it's easier because the daemon only needs to exit with a zero-state that all is not really new and was not better with sysvinit, it only was slow enough, full of sleep/usleep hacks and so most of the time by luck worked but with no guarantess anyways _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel