Systemd (ptui)

Originally written in 2017. I said, “It seems systemd can’t be avoided. I am annoyed at having to relearn stuff for a problem not worth solving”. I had another look in 2025, added some links as this time I wanted to move some job commands from cron to systemd i.e. run the programs/scripts periodically. Here are my notes as I learn to use it.

Originally, I made two service definition files, and posted them to this git folder, for deluge, and no2ip’s DNS Update Client. These are both daemons. In my github folder, there is also a script for enabling sysstat which references timers. I had to write a service file for no-ip’s dynamic update client. I remain confused about the choice of the type argument, but the link from red hat below is very clear & helpful.

So in looking to define services that ran periodically and ended, research and the links below, pointed me at .timer files. There are now separate scheduler files, which maybe an answer to the crontab permission problems I am having.

In the end, I cheated, I asked google gemini to write for me,

1. Systemd service for daemon script
2. Systemd service for scheduled script

You’ve got to laugh. As I worked though some of the documents below, I discovered that Raspbian now distributed a service definition for apt and updatedb, which is/was the problem I was looking to solve.

Links, found in 2025

I had another look in 2025, and in this case I was looking to run a script, not a daemon. I found these:

1. On Systemd
   • Setting Up a systemd Service from SUSE, comprehensive, includes how to make a service file and where to put it. It also categorises the service file types, such as .service & .timer.
   • How to Run Shell Script as Systemd in Linux from techadmin.net, illustrates the creation and installation of a null daemon, including the use of the systemctl commands.
   • The Free BSD man page, from freedesktop.org, the man page, comprehensive and dense and their syntax documentation.
2. Systemd Type argument
   • What sysadmins need to know about systemd’s oneshot service type from Red Hat. It says, The oneshot service type is useful if you want to trigger a workflow … If you were to use a simple service type, you would end up with a dead service status after the script runs and exits, which is misleading for anyone who doesn’t have knowledge of that particular service. So probably not, it looks like for this use case I need Type=simple, which is the default.
   • https://superuser.com/questions/1274901/systemd–vs-simple/1274913 from Red Hat, another article primarily about Type=
3. Systemctl
   • A tutorial on the commands from digital ocean, concentrates on the systemctl commands and parameters. It documents the is-active and is-failed arguments, which might be good to incorporate into my check_service script.
   • I found this at devdungeon.com; it has another example service file, with a dummy daemon, and a good summary of the necessary systemctl commands.
4. Timer files
   • How-do-i-use-systemd-to-replace-cron-jobs-meant-to-run-every-five-minutes from stackoverflow, examples of .service and .timer files and discussion about enabling the ,timer service. It’s not very helpful in writing the frequency argument.
   • How-to-schedule-tasks-with-systemd-timers-in-linux from Linux config.org, a detailed description on writing a .timer file. It includes a lsit of syntaxes for defining times such as daily or using a cron like syntax. It also documents the ‘list-timers’ argument for systemctl.
   • Linux: Task Scheduling with systemd Timers, by Yashwanth Rathakrishnan, a simple and short article, compares with cron, and states that one only needs to ‘start’ the timer. Presumably the common basename of the files ensures that it all works well.

2017 and an example from me

Some links from my original research …

1. About starting and stopping, from stack_exchange, and the importance of type=, it has a good write up of this, and I must have found it very useful. It is dated 2016
2. Type= simple or forking, from Red Hat, at superuser.com, and oneshot, made in 2018, another very comprehensive writeup of the Type argument.

An example,

[Unit]
Description=A description of the service
After=network.target 

[Service]
Type=simple # check link No 1 & 2 above
User=root
ExecStart=${program_path}/${program_name} 
#       explicit absolute path reqd

[Install]
WantedBy=multi-user.target