Add support for s6-style readiness notification

[troglobit]

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 this notify 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 the pid:/run/foo.pid option slightly. When notifiy is set, the PID file /run/foo.pid is not created until the daemon has sent a notification. (For reference, when the notify option is not set the PID file is created as soon as the process has been forked off, as it does currently.)

[hongkongkiwi]

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.

[troglobit]

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.

[troglobit]

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:

• Rename:
  • 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.

[troglobit]

Final draft. This one should work without too many ambiguities. What do you think @wkz?

[troglobit]

Change in state names, and thus automatic conditions, now rolled out to the master branch.