[systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown

Reindl Harald h.reindl at thelounge.net
Thu Jan 17 05:10:33 UTC 2019



Am 17.01.19 um 06:04 schrieb Jonathon Kowalski:
> On Thu, Jan 17, 2019 at 4:49 AM Christopher Cox <ccox at endlessnow.com> 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


More information about the systemd-devel mailing list