Here we go. You got an old web app that start/stop/restart using initd scripts. This was well and good in the CentOS days. After some OS updates here and there, your web app now runs on Rocky 9.7. Trouble is on VM reboots, your web app does not start up automatically and you have 10 apps on the box. From time to time, CI/CD breaks because your web app process goes on zombie mode and you'll have to manually kill it.
What can you do? Move it from an initd to a systemd service. As to the why the Linux folks replaced or moved from initd to systemd, I'll let you google that around. Here are the steps to make your app run as a systemd service.
Create the SystemD Service File
[jpllosa@rocky-balboa ~]$ cat /etc/os-release
NAME="Rocky Linux"
VERSION="9.7 (Blue Onyx)"
...snipped...
[jpllosa@rocky-balboa systemd-stuff]$ cat my-web-app.service
[Unit]
Description=My Web App service
After=network.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=always
RestartSec=1
User=codesamples
ExecStart=/usr/bin/java -jar /opt/codesamples/my-web-app/my-web-app.jar --spring.config.location=/etc/codesamples/my-web-app/my-web-app.properties
[Install]
WantedBy=multi-user.target
[jpllosa@rocky-balboa systemd-stuff]$
What do all the mumbo jumbo above mean?
All .service file start with a Unit section which provides basic information about the service. The Description must not exceed 80 characters and must describe the service. The After tells systemd to only activate this service after this prerequisite. In this example, the service is activated after network connectivity is established. We have disabled any kind of rate limiting by setting StartLimitIntervalSec to 0. This rate limiting works in conjunction with Restart.
The Service section provides instructions on how to control the service. The simple Type means to start the service without any special considerations. The ExecStart clearly shows the command to run to start the service. The full path to the command and arguments are declared. User specifies the user under which the service should run. RestartSec configures the time in seconds to sleep before restarting the service. Restart is set to always, as the word says, the service will be restarted no matter what (e.g. process is terminated by a signal, non-zero exit code, termination due to out of memory, etc). There is a default timeout for starting, stopping and aborting of units, as well as a default time to sleep between automatic restarts of units. If the restart times out after several tries, the system will not try to restart the service. Therefore, we have set above StartLimitIntervalSec to 0, so it will try to restart the service to infinity and beyond.
WantedBy is used to create symlinks in .wants/ directories when the service is enabled. In this case, a symlink will be created under multi-user.target.wants. This indicates that the service should be started as part of the multi-user system.
Copy the above service file to where systemd service file reside. As seen below.
[jpllosa@rocky-balboa system]$ pwd
/etc/systemd/system
[jpllosa@rocky-balboa system]$ ls -ali
total 24
67738686 drwxr-xr-x. 10 root root 4096 Mar 17 13:27 .
863730 drwxr-xr-x. 6 root root 4096 Feb 10 13:45 ..
67824144 drwxr-xr-x. 2 root root 65 Feb 13 13:43 basic.target.wants
67750396 lrwxrwxrwx. 1 root root 37 Feb 10 12:27 ctrl-alt-del.target -> /usr/lib/systemd/system/reboot.target
67824045 lrwxrwxrwx. 1 root root 41 Feb 10 12:28 dbus-org.fedoraproject.FirewallD1.service -> /usr/lib/systemd/system/firewalld.service
67823100 lrwxrwxrwx. 1 root root 57 Feb 10 12:28 dbus-org.freedesktop.nm-dispatcher.service -> /usr/lib/systemd/system/NetworkManager-dispatcher.service
67750469 lrwxrwxrwx. 1 root root 43 Feb 10 12:27 dbus.service -> /usr/lib/systemd/system/dbus-broker.service
67750393 lrwxrwxrwx. 1 root root 41 Feb 10 12:29 default.target -> /usr/lib/systemd/system/multi-user.target
67736707 -rw-r--r--. 1 root root 394 Mar 17 13:27 my-web-app.service
905723 drwxr-xr-x. 2 root root 32 Feb 10 12:27 getty.target.wants
68554611 drwxr-xr-x. 2 root root 56 Feb 13 13:43 graphical.target.wants
34039637 drwxr-xr-x. 2 root root 4096 Mar 17 13:32 multi-user.target.wants
67823101 drwxr-xr-x. 2 root root 48 Feb 10 12:28 network-online.target.wants
67750466 drwxr-xr-x. 2 root root 71 Feb 10 12:28 sockets.target.wants
101399263 drwxr-xr-x. 2 root root 4096 Feb 10 12:28 sysinit.target.wants
956462 drwxr-xr-x. 2 root root 56 Feb 10 12:28 timers.target.wants
Starting and Enabling the Web App
Now that the service is ready. Let's start up the web app.
sudo systemctl start web-app
If there are no error, you can then enable the web app so it will start at boot. You don't need to worry about reboots. The web app will automatically start up now.
sudo systemctl enable web-app
[jpllosa@rocky-balboa system]$ cd multi-user.target.wants/
[jpllosa@rocky-balboa multi-user.target.wants]$ ls -ali
total 8
34039637 drwxr-xr-x. 2 root root 4096 Mar 17 13:32 .
67738686 drwxr-xr-x. 10 root root 4096 Mar 17 13:27 ..
34113015 lrwxrwxrwx. 1 root root 38 Feb 10 12:28 auditd.service -> /usr/lib/systemd/system/auditd.service
34113143 lrwxrwxrwx. 1 root root 39 Feb 10 12:28 chronyd.service -> /usr/lib/systemd/system/chronyd.service
34039686 lrwxrwxrwx. 1 root root 37 Feb 10 12:27 crond.service -> /usr/lib/systemd/system/crond.service
34125258 lrwxrwxrwx. 1 root root 50 Mar 17 13:31 my-web-app.service -> /etc/systemd/system/my-web-app.service
34113189 lrwxrwxrwx. 1 root root 41 Feb 10 12:28 firewalld.service -> /usr/lib/systemd/system/firewalld.service
34124734 lrwxrwxrwx. 1 root root 37 Mar 17 13:29 httpd.service -> /usr/lib/systemd/system/httpd.service
34113963 lrwxrwxrwx. 1 root root 42 Feb 10 12:28 irqbalance.service -> /usr/lib/systemd/system/irqbalance.service
34112994 lrwxrwxrwx. 1 root root 37 Feb 10 12:28 kdump.service -> /usr/lib/systemd/system/kdump.service
34131546 lrwxrwxrwx. 1 root root 43 Feb 10 12:41 nessusagent.service -> /usr/lib/systemd/system/nessusagent.service
34112403 lrwxrwxrwx. 1 root root 46 Feb 10 12:28 NetworkManager.service -> /usr/lib/systemd/system/NetworkManager.service
34039638 lrwxrwxrwx. 1 root root 40 Feb 10 12:27 remote-fs.target -> /usr/lib/systemd/system/remote-fs.target
34111121 lrwxrwxrwx. 1 root root 39 Feb 10 12:28 rsyslog.service -> /usr/lib/systemd/system/rsyslog.service
34347699 lrwxrwxrwx. 1 root root 43 Feb 10 13:44 sentinelone.service -> /usr/lib/systemd/system/sentinelone.service
34113102 lrwxrwxrwx. 1 root root 36 Feb 10 12:28 sshd.service -> /usr/lib/systemd/system/sshd.service
34112926 lrwxrwxrwx. 1 root root 36 Feb 10 12:28 sssd.service -> /usr/lib/systemd/system/sssd.service
[jpllosa@rocky-balboa multi-user.target.wants]$
More Commands
Try the commands below to check the status, stop, or restart your web-app service.
sudo systemctl status web-app
sudo systemctl stop web-app
sudo systemctl restart web-app
Run App as SystemD Service
You can now sit back and relax. No more panic mode after VM reboots and when other people complain why things aren't working as they are supposed to. Goodbye zombie processes. Congratulations, you have automated yourself out of a job.
More Rocky Linux tips here...