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.
Services are stored in either
/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
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:
[Unit] Description=Networking Before=getty@.service After=dev-tty1.device [Service] ExecStart=-/etc/init.d/networking start Type=oneshot [Install] WantedBy=multi-user.target
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:
[Unit] Description=SSH Server Before= After=syslog.target [Service] ExecStart=-/etc/init.d/dropbear start ExecStop=-/etc/init.d/dropbear stop ExecReload=-/etc/init.d/dropbear restart Type=forking [Install] WantedBy=multi-user.target
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
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