Thursday, March 26, 2026

Run App as SystemD Service Example

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...

Friday, March 6, 2026

Deploy to Kubernetes Example

Alright, now that you got a docker image in the previous example, Dockerize Spring Boot App Example, what now? The most obvious next step is to spin up the docker image in a Kubernetes cluster. But GKE (Google Kubernetes Engine) is bloody expensive for us mere mortals. Luckily we can practice Kubernetes stuff with Docker Desktop.

Assumptions

I'm assuming you have read my previous example, Dockerize Spring Boot App Example, So you should have the following already set up.

  • Docker Desktop 4.55.0
  • Windows 11 Home 10.0.26200
  • IntelliJ IDEA 2023.3.4 (Community Edition)
  • OpenJDK 17.0.10
  • Crowsnest, example Spring Boot App
  • Lens 2025.6.261308-latest

Docker Desktop

First up is to start a Kubernetes cluster via Docker Desktop. Should just be a bunch of clicks. I just chose a single node cluster (Kubeadm). You should have something like below:

And if you have Lens K8S IDE. You'll have something like below.

Deploy to Kubernetes

First, let's check our image (docker images). Like so:


C:\workspace>docker images
                                                                                                    i Info →   U  In Use
IMAGE                                                                   ID             DISK USAGE   CONTENT SIZE   EXTRA
crowsnest:v1.0.0                                                        b9bfb190828e        567MB          197MB    U

Let's make sure we deploy to docker desktop kubernetes.


C:\workspace>kubectl config use-context docker-desktop
Switched to context "docker-desktop".

And the fun starts, create a deployment.


C:\workspace>kubectl create deployment crowsnest --image=crowsnest:v1.0.0
deployment.apps/crowsnest created

After deployment, take a look at Lens and Docker Desktop.

Or if you like CLI.


C:\workspace>kubectl get pods
NAME                        READY   STATUS    RESTARTS   AGE
crowsnest-f56bb85ff-t9dn9   1/1     Running   0          28m

Well and good so far. But our web app is not reachable from the browser yet. We need to expose the port of the pod so we can get to the web app. Do note that your pod name might be different from this example.


C:\workspace>kubectl expose pod crowsnest-f56bb85ff-t9dn9 --port=8080 --name=crowsnest --type=LoadBalancer
service/crowsnest exposed

C:\workspace>kubectl get services
NAME         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
crowsnest    LoadBalancer   10.100.27.69   localhost     8080:31912/TCP   97s
kubernetes   ClusterIP      10.96.0.1              443/TCP          4d3h

You should have something like below.

Perfecto! We should be able to access Crowsnest on the browser now. localhost:8080.

Thank you Docker Desktop for helping us save money by practicing kubectl stuff with you, instead of the expensive GKE. Deploying to GKE should be similar. Just need to point kubectl to GKE.

Undeploy from Kubernetes

Most importantly when doing this on a paid Kubernestes service, don't forget to delete the pod, service, deployment, etc. GKE billing is astronomical (delete the project too to be sure!) Here are the commands to undo what you've done.


C:\workspace>kubectl delete service crowsnest --now
service "crowsnest" deleted from default namespace

C:\workspace>kubectl delete deployment crowsnest --now
deployment.apps "crowsnest" deleted from default namespace

C:\workspace>kubectl get services
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1            443/TCP   4d3h

C:\workspace>kubectl get pods
No resources found in default namespace.

Deploy to Kubernetes Wrap Up

Yes, we did all of the above steps manually. Yes, this can all be automated. But before we automate stuff, we have to do it manually. For example, you can create a GitHub action workflow to do all of the above steps to spin up your docker image to GKE, just with a yaml file. That would be another story. Happy spinning!

Learn more k8s...