The s6 command
s6-frontend
Software
skarnet.org

The s6 set command

s6 set groups actions on service sets, telling the service manager what services should be enabled or disabled at boot time, and which should be masked, i.e. should not even appear in the list of services available at next boot.

Unlike s6 live, which deals with starting and stopping services that are currently running, s6 set is an offline tool, setting services in a state that remains theoretical until the user commits it and installs the set, making it live.

s6 set commands always operate on a "working set" of services, which is internally named current. It is not the set that is currently live; it is the set that is currently worked on.

Interface

     s6 set subcommand [ subcommand_options... ] [ args... ]

Subcommands

help

s6 set help prints a short help message summarizing the options and usage of the s6 set command. It is not as detailed as this page.

save

Interface

     s6 set save [ -f ] name

• s6 set save saves a copy of the current working set into a set named name.
• name can be loaded by s6 set load name.

Options

-f, --force

If a set named name already exists, overwrite it with a copy of the current working set. By default, the command exits with an error instead of overwriting.

load

Interface

     s6 set load name

• s6 set load replaces the current working set with the set stored as name.
• No options are defined.

delete

Interface

     s6 set delete names...

• s6 set delete deletes the saved sets named names...
• No options are defined.

list

Interface

     s6 set list [ -E | -e ]

• s6 set list lists all the services in the current set, printing their names on stdout, one per line.

Options

-E, --with-essentials

List all the services, including the essential ones. This is the default.

-e, --without-essentials

Do not list essential services.

status

Interface

     s6 set status [ -E | -e ] [ names... ]

• s6 set status lists the services named names... in the working set with their current prescription, i.e. the state that they should be in at boot time: masked, disabled (listed as usable), enabled (listed as active), or essential (listed as always).
  • masked: the service will not even appear in the live service database, it will be entirely omitted. If a service depends on a masked service, it should be masked too, otherwise the set is said to be inconsistent.
  • usable: the service will be listed in the live service database but will not be brought up by default at boot time. It can later be brought up manually via the s6 live start command.
  • active: the service will be brought up by default at boot time. It can later be brought down manually via the s6 live stop command.
  • always: the service is considered essential: it will always be brought up at boot time and it cannot be brought down without special options to force it down; it normally stays up until the machine is shut down. Essential services are marked as such in the stores and generally should not be tampered with via s6 set commands.
• The service name is normally followed by a slash (/) then the name of the prescription the service is in. On a terminal with util-linux support every line is pretty-printed into columns instead.
• If names... is empty, all the services in the set are printed along with their prescriptions.

Options

-E, --with-essentials

Prints all the listed services, including the essential ones. This is the default.

-e, --without-essentials

Do not print essential services.

enable, disable, mask, unmask, make-essential

These subcommands are the bread and butter of the s6 set commands. They allow the user to tailor the boot sequence to their needs without touching the currently running database.

Interface

     s6 set enable|disable|mask|unmask|make-essential [ -f ] [ -n ] [ -I fail|warn|pull ] [ services... ]

• These subcommands are built with the same model and do the same thing: they move the services listed in services... from their current prescriptions to another.
  • mask hides the services. Masking means that the service will not appear in the live service database at all, it will not be listed, it will not be usable until it is unmasked in a new working set that is subsequently committed and installed. Masking is useful when the stores provide services that come from random installed packages, the user never wants to run these services, and it's just better not to see them.
  • unmask and disable put the services in the usable prescription, i.e. unmasked and disabled.
  • enable puts the services in the enabled prescription.
  • make-essential enables the services and marks them as essential. This command should normally not be used: essential services are marked as such in the stores and should not be touched. The command exists for troubleshooting purposes.
• Dependencies across services are computed and the command will print a message if the change would make the set inconsistent.

Options

-f, --ignore-dependencies

Only change the services listed in services, don't compute dependencies.

-n, --dry-run

Do not perform the change; only show what would be done and check whether the set would be made inconsistent.

-I what, --if-dependencies-found=what

What to do when services have dependencies, or reverse dependencies, that are not listed in services.... what can be fail, warn, or pull.

• fail: abort the operation with an error message.
• warn: perform the operation with a warning message. The set might be inconsistent afterwards, that can be changed by manually changing the dependencies or by fixing the set (see below).
• pull: resolve inconsistencies by pulling the dependencies into the same prescription as the listed service. For enable, service dependencies are made active as well. For disable, reverse dependencies are disabled as well. For mask, reverse dependencies are masked as well.

check

Interface

     s6 set check [ -F ] [ -d | -u ] [ -E | -e ]

• s6 set check checks the current working set for inconsistencies, printing anything it finds to stdout.

Options

-F, --fix

Also attempt to fix the inconsistencies.

-E, --no-force-essential

If fixing the set involves changing a service flagged as essential to a prescription that is not always, or a service not flagged as essential to the always prescription, print an error message and exit. This is the default.

-e, --force-essential

If fixing the set involves changing a service flagged as essential to a prescription that is not always, or a service not flagged as essential to the always prescription, perform the change and continue. This is normally not necessary with a list of stores providing consistent services.

-d, --down

Fix the set by disabling or masking services. If service A depends on service B and B is masked or disabled, change A to be masked or disabled as well. This is the default.

-u, --up

Fix the set by enabling or unmasking services. If service A depends on service B and A is unmasked or enabled, change B to be unmasked or enabled as well.

commit

Interface

     s6 set commit [ -f ] [ -K ] [ -D defaultbundle ] [ -h fdhuser ]

• s6 set commit commits the current set: it attempts to compile a service database out of the set.
• This command must be run once all desired modifications have been done to the set and that its consistency has been ensured, for instance by a s6 set check -F command.
• Once the set has been committed, in order to actually be used it must be installed via the s6 live install command.

Options

-f, --force

Compile the database even if no change has been performed since the last time the set was committed.

-K, --keep-old

If an old compiled database exists for the set, do not delete it and instead print its path to stdout. By default the old database is deleted when the set is successfully committed.

-D defaultbundle, --default-bundle=defaultbundle

The name of the bundle that holds all active and always services and that will be started at boot time. There is generally no reason to change the default, which depends on the distribution and is probably called default.

-h fdhuser, --fdholder-user=fdhuser

Specify the fdholder user for the compiled database built from the set. This must be a user name defined in the /etc/passwd file or whatever user database the system uses. The default is root and that is fine.