Recent Changes -

Dinit {Main}

Dinit is a service supervisor with dependency support which can also act as the system "init" program. It was created with the intention of providing a portable init system with dependency management, that was functionally superior to many extant inits.

Installation

Install the dinit package.

Installation of services

Dinit service packages are named package_name-dinit and, when installed, will be available in /etc/dinit.d.

Programs

  • dinit
  • dinitcheck
  • dinitctl

Files/Directories

  • /etc/dinit.d/ - user-installed dinit service files
  • /usr/lib/dinit.d/ - system dinit service files
  • /etc/dinit.d/config/ - configurations for dinit services
  • /etc/dinit.d/boot.d/ - dinit services that run on boot
  • /usr/lib/dinit/ - dinit wrapper scripts
  • /var/log/dinit/ - logs for dinit services
  • /etc/dinit.d/service_name-pre - preparation service, in some cases, this is needed because the "preparation" must be run as root but the service itself must be run as its own user

Basic usage

Nearly every interaction with dinit are done with the dinitctl program.

  • Start service: # dinitctl start service_name
  • Stop service: # dinitctl stop service_name
  • Restart service: # dinitctl restart service_name
  • Enable service: # dinitctl enable service_name
  • Disable service: # dinitctl disable service_name
  • List services: # dinitctl list

dinitcheck is usually used if to check if there is any problem with the dinit service directory, it will check for any syntax errors, invalid parameter values, and dependency cycles.

Service file structure

A typical service file looks like this: 

 type = process | bgprocess | scripted | internal
 command = /path/to/servicename
 restart = (boolean)
 smooth-recovery = (boolean)
 logfile = ...
 depends-on = (service name)
 waits-for = (service name)

There are four types of dinit services:

  • process, for foreground daemons
  • bgprocess, for forking daemons
  • scripted, for oneshots
  • internal, which is only useful inside dinit and is usually used to "gather" lots of dependencies into one big dependency, or similar to "bundle" in s6.

There are three types of dependencies:

  • depends-on is hard dependency, so if any service is named here, it must run no matter what before the service is started
  • depends-ms is a milestone dependency, so while the rules of depends-on apply when starting service, if the dependency stopped, the dependent will still run
  • waits-for is soft dependency, while the service will wait for its dependency to run, it will still run if the dependency fails

For more details, see dinit-service(5).