Closed troglobit closed 1 year ago
Just a thought I had, for "ready" conditions we could use the existing automatic conditions right?
e.g. <service/myservice/ready>
To make it backwards compatible it would probably need to set both:
<service/myservice/running>
and <service/myservice/ready>
but that way it means you don't have add a "notify:condition" flag and it just happens transparently and users can trigger something off ready, or off running.
Yeah that was my intention, but I just realized the "ready" as in readiness we're talking about here is not the same as the Finit state machine's state "READY" :-/
For clarity we might have to consider another name for ready:script
or the Finit state's name.
After a good cup of coffee I'm leaning towards changing the SVC state machine's state names. I think you @hongkongkiwi are the only one using the automatic conditions currently, so you might be affected by the change. Therefore I'm curious to hear what you think about this:
WAITING
-> STOPPED
READY
-> WAITING
That way the STOPPPED
state descries the state of the process (SIGSTOP:ed) and WAITING
clearly means waiting for a condition to be asserted.
Update: I'm doubting the naming of more states, e.g. STOPPING -> HALTING
, but it's really hard to find fitting names that match both what they represent and also be user-friendly wrt. the initctl commands and output. (STOPPING
is better since that's what you ask it to with initctl ...)
Update 2: Alternatively rename WAITING -> FLUX
. Might be better since the service's conditions are in flux. This state is for when initctl reload
is called and all processes are temporarily SIGSTOP:ed until Finit knows what to do with them.
Final draft. This one should work without too many ambiguities. What do you think @wkz?
Change in state names, and thus automatic conditions, now rolled out to the master branch.
systemd provides the
sd_notify()
family of APIs, which supports many different commands that can be sent from a daemon to systemd, e.g.READY=1\n
s6 supports a
/run/service/foo/notification-fd
which the daemon is expected to send a\n
and then close when it's ready. E.g., mdevd supports the-D fd
option.This issue suggests adding a
notify[:condition]
option for service stanzas be added. When thisnotify
option is set the third (3rd) descriptor passed to a daemon is this notification channel. The command line to a daemon can then comprise a"%n"
format specifier, e.g.mdevd -D %n ...
which Finit replaces with the file descriptor number.The
notifiy
option would also change the semantics of thepid:/run/foo.pid
option slightly. Whennotifiy
is set, the PID file/run/foo.pid
is not created until the daemon has sent a notification. (For reference, when thenotify
option is not set the PID file is created as soon as the process has been forked off, as it does currently.)