From 87b8fcabeecf2a9cff2ca596da54d6c1cf17d89f Mon Sep 17 00:00:00 2001 From: Laurent Bercot Date: Sun, 14 Jun 2026 04:37:32 +0000 Subject: Prepare for 0.7.0.0; lots of changes! - s6-rc-bundle deleted. Changing bundles without recompiling is not supported anymore. (It works, but it incentivizes poor workflows; it is better to handle stuff at the source level and recompile when in doubt, that's what s6-frontend does.) - new db format, need to recompile and use s6-rc-format-upgrade on new live db - support for the reload-signal file in service directories - new reload scripts for oneshots (which is why the db format has changed) - new "s6-rc reload" command, calling s6-svc -l on longruns (which makes use of reload-signal, HUP by default) and the reload script on oneshots - the live state now tracks when a service has been explicitly brought up as opposed to by pulled by dependencies. Nothing uses the feature for now but now the tech is there for an auto-stop-if-unneeded feature. --- doc/faq.html | 7 --- doc/index.html | 5 +- doc/overview.html | 10 ---- doc/s6-rc-bundle.html | 138 ------------------------------------------------- doc/s6-rc-compile.html | 26 +++++----- doc/s6-rc.html | 3 +- doc/upgrade.html | 13 ++++- 7 files changed, 27 insertions(+), 175 deletions(-) delete mode 100644 doc/s6-rc-bundle.html (limited to 'doc') diff --git a/doc/faq.html b/doc/faq.html index 23797f1..59b1d82 100644 --- a/doc/faq.html +++ b/doc/faq.html @@ -339,13 +339,6 @@ you don't want up anymore: s6-rc -p change runlevel-2.

Bundles are easy to use, they're flexible, and they're powerful. They give you the same level of functionality as runlevels would, and more. -You can even add bundles to compiled service databases - including the -live one - or remove bundles from them without having to recompile them: -that's what the s6-rc-bundle utility is -for. -

- -

When in doubt, use bundles.

diff --git a/doc/index.html b/doc/index.html index 426bdb5..1278c18 100644 --- a/doc/index.html +++ b/doc/index.html @@ -69,8 +69,8 @@ requirement if you link against the shared version of the skalibs library.

The current released version of s6-rc is -0.6.2.0. -You can access its checksum here.

0.7.0.0

here

Alternatively, you can checkout a copy of the s6-rc git repository: @@ -106,7 +106,6 @@ the previous versions of s6-rc and the current one.

Online tools: managing your live services

Live bundle modifications

- It is possible to change bundle definitions in a compiled service -database, including the live one, without recompiling everything by -calling s6-rc-compile. The -s6-rc-bundle tool can edit compiled -databases to add bundles to them, or delete bundles from them. -

Management of source definition directories

diff --git a/doc/s6-rc-bundle.html b/doc/s6-rc-bundle.html deleted file mode 100644 index fbe8d06..0000000 --- a/doc/s6-rc-bundle.html +++ /dev/null @@ -1,138 +0,0 @@ - - - - - - - s6-rc: the s6-rc-bundle program - - - - - - -

-s6-rc
-Software
-skarnet.org -

The s6-rc-bundle program

- s6-rc-bundle is a tool to add or delete bundles from a compiled -service database without having to recompile it from source. -

- It is an offline tool, i.e. you can run it on any -compiled service database without actually having a live set -of services managed by s6-rc. However, if you do have a live -set, you can still run s6-rc-bundle on the current database (and -it is the default); it won't interfere with your normal service -operation. -

Interface

-     s6-rc-bundle help
-     s6-rc-bundle [ -f ] [ -l live ] [ -c compiled ] [ -b ] add bundlename contents...
-     s6-rc-bundle [ -f ] [ -l live ] [ -c compiled ] [ -b ] delete bundlenames...
-     s6-rc-bundle [ -f ] [ -l live ] [ -c compiled ] [ -b ] multiple args...
-

s6-rc-bundle expects to find a compiled service database -in compiled; by default it uses the service database -used by the live state in live.
Depending on the arguments, it adds a bundle definition to this database, or -deletes a bundle definition from it, or performs multiple additions/deletions.

Options

-c compiled : operate on a -compiled service database in compiled instead of -the current live one.
-l live : assume the live -state is in live. This option is ignored if the --c option has been given. Default is -/run/s6-rc. The default can be changed at package -compilation time, by giving the --livedir=live -option to ./configure.
-f : force. s6-rc-bundle will not complain -when given a nonexisting name to delete (it will do nothing), or -when given an existing name to add (it will replace the definition). -By default, s6-rc-bundle will complain and exit when asked to delete a -nonexistent name or to add an existing name.
-b : blocking lock. If the database is currently -being used by another program, s6-rc-bundle will wait until that -other program has released its lock on the database, then proceed. -By default, s6-rc-bundle fails with an error message if the database -is currently in use.

Exit codes

0: success
1: identifier already exists in service database
3: identifier not found in service database
4: invalid or corrupted service database
5: wrong identifier type for the given command
100: wrong usage
111: system call failed

Subcommands

s6-rc-bundle help

- Prints a help message on stdout. -

s6-rc-bundle add bundlename contents...

- Adds a bundle named bundlename to the database, representing -the services listed in contents. The arguments in contents... -are resolved before the database is modified by the -s6-rc-bundle invocation. -

s6-rc-bundle delete bundlenames...

- Deletes bundles listed in bundlenames.... -

s6-rc-bundle multiple args...

- Performs multiple bundle deletions and additions. This subcommand is best -used in an execline -script, because it uses -blocks. -

-args... is composed of: -

One block listing bundle names that will be -deleted from the database.
Zero or more addition definitions, each of them composed of: -
- One argument that is the name of the bundle to add
- One block listing the services contained in the -new bundle. The names in the block are resolved before any addition -or deletion is made to the database.

For oneshots

Two regular files named up and down, which -must each contain a single Unix command line. The files will be interpreted by the +
Three regular files named up, down, and reload, +which must each contain a single Unix command line. The up file is +mandatory, the other two are optional; if they are absent, they are considered +empty, i.e. nothing happens when the corresponding script is executed and the +operation is considered a success. +The files will be interpreted by the execlineb lexer at compile time and the results will be stored into the compiled database in an internal form. up will be run when -the service is started, and down will be executed when the service -is stopped. up is mandatory, but down is optional; -if no down file is provided in the source definition directory, -then it is treated as the empty script. If a script is empty, -then s6-rc will consider that the corresponding transition for this service -does nothing and always succeeds.

down

reload

- up and down are interpreted by + up, down and reload are interpreted by execlineb, but that does not mean they have to be entirely written in the execline language. The execlineb lexer is only used because it can compile a Unix command line from a text file and store the compiled result, whereas a shell would have to be invoked -everytime the script is run. There are many ways to write up and -down scripts: +everytime the script is run. There are many ways to write these scripts:

down

/etc/init.d/service stop

Don't think you have to learn all the intricacies of the execline language -just because the up and down scripts get lexed by it. -You don't. +just because the up, down and reloadscripts get +lexed by it. You don't.

For longruns

s6-rc reload

s6-svc -l

reload-signal

up

RC_RELOAD