Linux Startup Process with Systemd

As of the latest Angstrom OpenEmbedded builds, the build produces a system which uses systemd rather than System-V in the init process. The old System-V is still somewhat functional, but we have witnessed that the process does not seem to always start shell scripts in the order provided by the two-digit sequence number in the /etc/RC.x directories.

In any case, to move into the future it is recommended that the Systemd process be used.

Systemd info can be found on the web, the man pages are pretty useful to understand how things work:
Systemd manual
Systemd.service(5) manual
Systemctl manual
Useful Systemd wiki

Basic Info

Services are stored in either /lib/systemd/system/ or /etc/systemd/system/. Services in /etc/systemd/system/ take precedence over those in /lib/systemd/system/. So it is recommended to place custom services in /etc/systemd/system/.

The system directory contains the TASKNAME.service files along with TASKNAME.wants directories. If a service has a corresponding .wants directory, then any symlinks in that directory for other services cause those services to become dependencies of the service named in the .want directory name.

The start-up for the ARMs is generally the multi-user-target.service. The folder /lib/systemd/system/multi-user-target.wants/ contains symlinks to services one level up that must be started before the boot is complete.

Basics to creating a service that runs at startup

Here is an example to create a service that will setup networking, it will be called networking.service:


ExecStart=-/etc/init.d/networking start


Going line by line:
Description is name you want shown on startup, so here during startup "Starting Networking" will be shown.
Before is a space delimited list of the services or targets that can't be started until this service has started.
After is a space delimited list of the services or targets that need to be started before this one service will start.
ExecStart tells what to execute to run the service. NOTE: Multiple ExecStart lines will be run sequentially.
Type tells systemd how to handle this service. In this case oneshot is used, which means systemd expects anything called by this service to be end before moving on to the next service. If Type is set to forking, systemd will expect the task being started to fork another process and then exit. This can be used for starting the main application without blocking the console (using & to execute).
WantedBy is the target that this service will be started for
For further information on .service formats and options refer to: systemd.service

Now that the service file is made, use systemctl to enable and setup all the appropriate sym links for this serice:

systemctl enable networking.service

Now on restart "Starting Networking" should be seen, to check its currents starts:

systemctl status networking.service

If networking.service needs to be edit, once editing is done run:

systemctl reenable networking.service

This will create any new links that need to be created.

Here is an example of a dropbear.service, which uses the forking type:

Description=SSH Server

ExecStart=-/etc/init.d/dropbear start
ExecStop=-/etc/init.d/dropbear stop
ExecReload=-/etc/init.d/dropbear restart




The systemctl utility can be used to check status, control startup/shutdown services, and loads of other stuff. See man page for full usage.

Simple status check:

systemctl status app.service
app.service - Start the main application
          Loaded: loaded (/lib/systemd/system/app.service; static)
          Active: active (running) since 02:15:24 +0000; 22h ago
         Process: 2492 ExecStart=/etc/init.d/app start (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/app.service
                  m 2497 /home/user/bin/main-app

Temporary Files

To create directories, files, or links on startup tmpfiles.d is used. This requires a .conf to be made either in /usr/lib/tmpfiles.d/ or /etc/tmpfiles.d/. With /etc/tmpfiles.d overriding any .conf with the same name in /usr/lib/tmpfiles.d. The naming convention is serivice_name.conf. For example the networking.service would have a networking.conf.
Here is an example of a networking.conf that creates a link from an interfaces file that is generated in memory then linked to /etc/networking/.


L /etc/network/interfaces - - - - /var/volatile/interfaces

The L is for generating a link.

For more information of refer to the tmpfiles.d manpage

Go to top
Add picture from clipboard (Maximum size: 1 GB)