The syntax overview no longer describes a line-based format, since that
is not what the rest of the documentation shows. It now covers the
grammar, the two naming conventions, the nine aliases, and the leading
'-' on a path, and it says plainly that both formats are still read and
told apart per file by content. Without that, a reader with an
existing configuration is left wondering what happened to it.
service-opts.md was a list of modifiers to place between a directive
and its command, so it needed rewriting rather than translating: there
are no positions left to describe. It is now grouped by what the
settings do.
conditions.md needed correcting. It presented '!' as a condition
prefix alongside '~'. It is neither a condition nor a negation, it is
a flag on the block that means one thing on a service and another on a
run or task, so it is spelled reload-signal and required here, and the
page maps the old form to both.
Two things the pages claimed are not true. The kill delay range is
1-300, not 1-60, and stop and reload scripts are no longer run without
a timeout.
ChangeLog.md keeps its line-based examples. Those sit in historical
release entries, and rewriting them in a syntax that did not exist at
the time would misdate the format.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
- Add `type:forking` service option to trigger guessing pidfile to
watch for, instead of `pid:!foo` option, which is not intuitive.
This option may likely also survive into the new file format :)
- Update docs and add examples
- Update start-stop-serv.sh test case with this new variant
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
With the recent changes to the condition handling it has become more and
more evident that the canonical reference for a task/run/service is the
NAME:ID representation. Up until now we've kept the older JOB:ID for
some sort of compatibility fallback.
This patch removes the support to simplify maintenance going forward.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The generic term for a non-running service is blocked, but a service may
be blocked for several different reasons. When a user stops a service
with `initctl stop` the intuitive expected output from `initctl show` is
"stopped" not "blocked".
When the user later restarts the service with `initctl start` it may of
course be blocked due to wrong runlevel or a missing condition. As can
be expected from the service's configuration.
The rest of the patch refactors the internal API names a bit to reflect
this change.
Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
This is a first effort at cleaning up and consolidating all information
about the new service state machine and how conditions control this
state machine.
Also, clarified and added sections for all documents regarding how
services and conditions relate.
Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
Joachim Wiberg