The native mechanism for this system is the service bundle.
One can, however, import systemd unit files.
The system-control convert-systemd-units command takes systemd unit files and converts them to a service bundle directory.
This conversion program allows software packagers to quickly construct a service bundle if they already have systemd unit files for a service.
(It also allows system administrators to do this in the case that software packagers have not.)
Five kinds of unit can be converted:
a target unit with no associated service, that simply aggregates other services and targets, or that operates as a milestone;
a simple service unit;
a templatized service unit;
a socket unit that invokes a simple service unit of the same name;
a socket unit that invokes a templatized service unit of the same name.
There are a few restrictions:
The service must be a forking, oneshot, or simple service; not a dbus or notify service.
The socket must be a TCP, UDP, local-domain stream, or local-domain datagram socket. Sequenced packet socket and FIFOs are not convertible, although there's nothing in principle stopping (say) UCSPI-FIFO tools and conventions from being invented and used.
Some esoteric options are not convertible. Nor are some Linux-kernel-only options.
These cover a large number of unit files, in practice.
convert-systemd-units breaks down the unit files and builds run, start, and service scripts that use the various utility programs to set up a service's run-time environment in the way specified by the unit files.
(This is only a subset of what a run script can actually do.)
A User= directive becomes a setuidgid command, for example.
The conversion deals with several quirks of systemd:
It was undocumented for a long time that systemd always sets the HOME, USER, and LOGNAME environment variables whenever a User= directive says to change the user account.
It's not documented, but systemd always changes directory when it starts a service. It explicitly changes to the root directory when no WorkingDirectory= directive is given.
The daemontools convention is for services to be run in their service directories.
Some daemons have been found to rely upon the undocumented systemd behaviour of being in the root directory.
A fair few directives can occur in both a socket unit or its associated service unit.
There are several extensions to the systemd unit specification provided by the conversion process, to allow a unit file to specify things that systemd doesn't have but that service bundles have:
The systemdWorkingDirectory= setting (defaulting to true) if false causes the generated bundle to not bother mimicking the working directory quirk of systemd.
Set this on services and targets where the daemon program is happy to run in the service directory.
The systemdUserEnvironment= setting (defaulting to true) if false causes the generated bundle to not bother mimicking the user environment variables quirk of systemd.
Set this on services and targets where the daemon program has no need for the HOME, USER, LOGNAME, or SHELL environment variables.
The ExecStart= setting does not require that the program be named with an absolute pathname, unlike systemd.
Generated run scripts will use nosh, which searches the PATH.
(systemd does not search PATH.)
This makes it possible, for example, for a single service unit file to just say ExecStart=cupsd without needing to have two different unit files, one saying ExecStart=/usr/sbin/cupsd for Linux systems and one saying ExecStart=/usr/local/sbin/cupsd for BSD systems.
The LimitMemory= setting translates to softlimit's -m option, to set multiple "memory" resource limits in one go.
The EnvironmentDirectory= setting specifies a directory to be read by envdir.
Set this on a service that is configured via an envdir environment directory.
The EnvironmentUser= setting specifies an account to be recorded in the environment by envuidgid.
Set this on a service where the main daemon program changes its own process UID and GID, but expects to be told via environment variables what UID and GID to run as.
The EarlySupervise= setting (defaulting to true for "etc" bundles and false for others) if true causes the generated bundle to use a supervise directory in /run/service-bundles/early-supervise/.
This is for avoiding access to /var before it is mounted, during the bootstrap process, and is mainly used for "sysinit" services and system targets that are in /etc.
The StoppedBy= setting defines a stopped-by relationship to other services, stored in the generated bundle.
This is the inverse of the conflicts relationship.
By default, unless the DefaultDependencies=false setting is used, services are stopped by the "shutdown" target in addition to anything specified in this setting.
The ProcessGroupLeader= setting (defaulting to false) if true causes the generated bundle to run the daemon as a process group leader with setpgrp.
The SessionLeader= setting (defaulting to false) if true causes the generated bundle to run the daemon as a session leader with setsid.
The TTYPrompt= setting (defaulting to false) if true causes the generated bundle to invoke login-prompt.
The ExecRestartPre= setting allows one to specify extra commands to be run in the (automatically generated) restart script.