Service management

Chimera relies on Dinit as its service manager and init system. On top of Dinit itself, it comes with its own suite of core services as well as extra tooling for additional functionality.

Dinit is a supervising service manager, which means it tracks the daemons it manages and is fully aware of their current state. This is in contrast to the traditional rc systems, but similar to projects like Systemd, S6 and Runit.

It is dependency-based, which means services can specify which other services they depend on to control startup and shutdown ordering. In addition to that, it also allows for explicit startup ordering without dependency links, and provides various other functionality, such as oneshots, scripted services, readiness notification, rudimentary socket activation and so on.

Basic usage

Dinit is controlled with the dinitctl command. For example to enable or disable a service:

# dinitctl enable sshd
# dinitctl disable sshd

What this does is simply create a symlink in /etc/dinit.d/boot.d. The dinitctl command only works when the service manager is running.

To get a status of a service:

# dinitctl status sshd

To list activated services and their status:

# dinitctl list

Service files

Dinit relies on service files to describe the services. A service file can look for example like this:

# foo service
type = process
command = /usr/bin/foo --run-on-foreground
depends-on = bar
waits-for = baz
before =

This is a process service, which means Dinit will supervise it. It could also be a bgprocess service which cannot reliably be supervised, or a scripted service that is just a oneshot.

It depends on bar, which means bar will start first. On shutdown, foo will stop first. It will also wait for baz to come up before starting, but will not form a dependency link. And lastly, it will try to start before

Default service directories

Chimera’s Dinit configuration will scan several directories for service files:

  • /etc/dinit.d
  • /usr/local/lib/dinit.d
  • /usr/lib/dinit.d

Links to services enabled by the admin are in /etc/dinit.d/boot.d.

The system can install some default-enabled Dinit links which will be in /usr/lib/dinit.d/boot.d. Those are installed by special packages suffixed with -dinit-links and can be masked by the admin.


Chimera’s services suite comes with support for targets. Targets are services which do not track any daemons (they are Dinit’s internal service type) and act as ordering sentinels.

Outside of their name, they are ordinary services; the name has the .target suffix. There is a variety of targets that comes with Chimera’s core service suite.

Notable targets that are used by regular daemon services include as well as and There are also targets that define a concrete event, for example for when date/time has been synchronized, and

The documentation is currently lacking but you can read up on all the targets here.

User services

Chimera comes with support for user services by default. While Dinit itself has satisfactory baseline support for user services, it has no infrastructure to manage the user instances. That’s why Chimera has its own system, turnstile.

This is implicitly activated and works out of box, so the user does not have to do anything. The daemon is configured via /etc/turnstile/turnstiled.conf.

By default, the following paths are scanned for user services:

  • ~/.config/dinit.d
  • /etc/init.d/user
  • /usr/local/lib/dinit.d/user
  • /usr/lib/dinit.d/user

Links to services enabled by user are in ~/.config/dinit.d/boot.d. The system can also enable some user services for all users implicitly, by placing links in /usr/lib/dinit.d/user/boot.d.

There are more things turnstile also does, such as managing the XDG_RUNTIME_DIR environment variable and directory as well as track the D-Bus session bus address in the user’s environment. See the Seat management page for more information.

User service lingering

By default, upon first login of the user, the user’s activated services come up, while upon last logout of the user, they are shut down. This is not always the desired behavior.

In order to fix that, turnstile provides the “linger” functionality. When this is on, user services come up with the first login as usual, but they do not shut down with the last logout.

By default, this is configured per user. To enable lingering for user myuser:

# touch /var/lib/turnstiled/linger/myuser

To disable it, simply remove the file.

Lingering is checked on last logout. That means if you log in, create the linger file and then log out, your services will stay up. If you log in again, remove the file and log out again, the services will shut down.


The system administrator can create the script /etc/rc.local, which is run after early init is done, and either before or in parallel with regular service startup.

This can be used to run things that are unfit for regular service handling.