|Applying C - Running Programs With Systemd|
|Written by Harry Fairhead|
|Monday, 14 October 2019|
Page 2 of 3
Assuming you have created the program executable in the directory and created the unit file, you can get systemd to notice it by restarting it. Most of your command line interaction with systemd is via the systemctl command.
You can even use it to create or edit a unit file:
sudo systemctl edit myService --full --force
This opens the default editor and creates a file called myService.service in /etc/systemd/system. If the unit already exists don't use --force.
If you just want to override a few parameters of an existing unit file you can also use:
sudo systemctl edit myService
which creates a file called override.conf under a directory at /etc/systemd/system/myService.service.
When you create a unit file systemd only knows about it after a reboot or a manual reload using:
sudo systemctl daemon-reload
After this systemd knows about your unit file but doesn't do anything with it. If you want it to start automatically then you have to use:
sudo systemctl enable myService
Following this myService will start at the next reboot. To stop this happening you simply use the same command with disable.
You can also start, stop and restart the unit. Notice that if you change the unit file you also have to use daemon-reload to make systemd reread the unit file. If you change the program executable then restart is enough to reload the code.
To summarize, some useful systemctl commands, including some not described in the text, are:
Of course to use any of these you add the command to systemctl, i.e.
sudo systemctl command
and the name of the unit where required.
So assuming that you have the program file in the home directory and the unit file given earlier you can set things up so that it is loaded at boot time using:
sudo systemctl daemon-reload sudo systemctl enable myService
and to run it without a reboot:
sudo systemctl start myService
At this point you might be wondering what permissions a service has?
If your service only needs a subset of root’s permissions then setting up a user and group just for it is a good way to allow for customization and sharing of resources.
To find out the current status of your program you can use the status command which also provides a short extract from its log. Although many of the legacy Linux log files are still supported, systemd is supposed to be used by programs to log events. The journal is a central store for all messages logged by the system and all units. It is a binary file and you need to use the journalctl command to read it. There are many forms of the command and it is worth finding out how to filter the logs for what you are looking for. To see the log output from myService all we need is:
sudo journalctl -f -a -umyService
The -f means show only new log messages and -a makes sure that the data that the service has sent to the log is treated as ASCII rather than as a binary blob.
When you see the output you will know exactly where the printf has been sending its text.
-- Logs begin at Fri 2019-03-22 06:20:23 UTC. -- Mar 23 17:38:57 MyServer myservice: Hello systemd world Mar 23 17:39:02 MyServer myservice: Hello systemd world Mar 23 17:39:07 MyServer myservice: Hello systemd world Mar 23 17:39:12 MyServer myservice: Hello systemd world . . .
When running as a service, your program's stdout and stderr are sent to the journal. You can change this using
This form starts the log file each time the system is rebooted. If you want to keep the log files use append: in place of file:.
Logs are deleted and recreated on each boot. If you want them to persist you have to configure the journal in detail, including how long you want them kept and how much space can be allocated - consult the documentation.
|Last Updated ( Monday, 14 October 2019 )|