OpenLiteSpeed reloads without lswsctrl

[akansc]

Problem description

We run automated tests with various configurations to make sure that all the settings and configs work as expected (related to our software). We've noticed that OLS give flacky results on all rhel8 systems - centos8, alma8, rhel8 and rocky8, - the configs do not seem to be reloaded reliably.

Digging deeper revealed that the main issue is with the systemd itself, where a reload command in parallel not only gets ignored, but also breaks the initial reload command.

Working state

[root@localhost system]# date; systemctl reload openlitespeed; date
Wed Apr 22 20:15:52 EEST 2026
Wed Apr 22 20:15:55 EEST 2026
[root@localhost system]# date; systemctl reload openlitespeed; date
Wed Apr 22 20:15:58 EEST 2026
Wed Apr 22 20:16:01 EEST 2026

Reloads are confirmed in journal:

Apr 22 20:15:52 localhost.localdomain systemd[1]: Reloading OpenLiteSpeed HTTP Server.
Apr 22 20:15:52 localhost.localdomain lswsctrl[19937]: [OK] Send SIGUSR1 to 19924
Apr 22 20:15:55 localhost.localdomain systemd[1]: Reloaded OpenLiteSpeed HTTP Server.
Apr 22 20:15:58 localhost.localdomain systemd[1]: Reloading OpenLiteSpeed HTTP Server.
Apr 22 20:15:58 localhost.localdomain lswsctrl[19959]: [OK] Send SIGUSR1 to 19947
Apr 22 20:16:01 localhost.localdomain systemd[1]: Reloaded OpenLiteSpeed HTTP Server.

Broken reloads

When a parallel reload gets issued:

[root@localhost system]# date; systemctl reload openlitespeed; date
Wed Apr 22 20:18:05 EEST 2026
Wed Apr 22 20:18:07 EEST 2026
+in parralel:
[root@localhost ~]# date; systemctl reload openlitespeed; date
Wed Apr 22 20:18:07 EEST 2026
Wed Apr 22 20:18:07 EEST 2026

Journal has only the beginning of the reload, but not the end:

Apr 22 20:18:05 localhost.localdomain systemd[1]: Reloading OpenLiteSpeed HTTP Server.
Apr 22 20:18:05 localhost.localdomain lswsctrl[20064]: [OK] Send SIGUSR1 to 20048

Basically, the first command vanishes when another command gets executed in parallel.
Timestamps show exactly the same exit time for both reload commands.

OLS Native systemd?

We haven't noticed this buggy systemd behavior with other services due to the very simple fact - reloads usually are just one signal sent to a service to reload the configs, which basically is instant, but OLS uses lswsctrl script for reload that has sleep commands hardcoded:

The OpenLiteSpeed systemd script /etc/systemd/system/openlitespeed.service uses lswsctrl script to reload the service:

ExecReload=/usr/local/lsws/bin/lswsctrl restart 

So the best case for reload when everything is working:
2 seconds here:

openlitespeed/dist/bin/lswsctrl

Line 191 in c607631

sleep 2

and 1 second here:

openlitespeed/dist/bin/lswsctrl

Line 165 in c607631

sleep 1

Which is always 3 seconds minimum.

Suggestion/Request

The main question is - can lswsctrl script be eliminated by using systemd natively?

Our tested example:

# should be added as /etc/systemd/system/openlitespeed.service
[Unit]
Description=The OpenLiteSpeed HTTP Server
After=network-online.target remote-fs.target nss-lookup.target lve_namespaces.service
Wants=network-online.target

[Service]
Type=forking
WorkingDirectory=/usr/local/lsws
PIDFile=/run/openlitespeed.pid
ExecStart=/usr/local/lsws/bin/openlitespeed
Restart=always
ExecReload=/bin/kill -USR1 ${MAINPID}
SuccessExitStatus=255

PrivateTmp=false
LimitMEMLOCK=infinity
LimitNOFILE=655350

[Install]
WantedBy=multi-user.target
Alias=lsws.service
Alias=lshttpd.service
Alias=litespeed.service

Nuances with systemd

The start/restart/reload seems to be working as expected with two exceptions that are worying:

1. We must use custom SuccessExitStatus due to some guardCrash and poll related return code, where the exit code 0 on successful exit would be preferred

SuccessExitStatus=255

otherwise we get:

Apr 23 07:52:49 localhost.localdomain systemd[1]: lshttpd.service: Main process exited, code=exited, status=255/n/a
Apr 23 07:52:49 localhost.localdomain systemd[1]: lshttpd.service: Failed with result 'exit-code'.

2. When starting litespeed, pid file gets created in a later stage than expected:

Apr 22 11:49:51 localhost.localdomain systemd[1]: Starting The OpenLiteSpeed HTTP Server...
Apr 22 11:49:51 localhost.localdomain systemd[1]: lshttpd.service: Can't open PID file /run/openlitespeed.pid (yet?) after start: No such file or directory
Apr 22 11:49:51 localhost.localdomain systemd[1]: Started The OpenLiteSpeed HTTP Server.

We would be very grateful to see native OLS systemd implementation.

[litespeedtech]

OLS actually need to do a graceful restart for reload configuration, restart will take some time, especially, when there are a lot vhost configurations to parse. PID will change.
Systemd is picky about the pid file, that's why our control script insert some sleep to make sure it is ready before return control to systemd.
Your way is that systemd immediately check pid file right after sending "kill" command, either picks up the old PID, or no PID, before new process is ready.
Back to back consecutive reloads are likely to fail no mater what we do with systemd signaling, graceful restart will take time to complete, forcing another reload before previous one has been completed is looking for trouble.

[akansc]

Agreed, It may take longer to reload, but the hardcoded sleeps do not account of the amount of configs or the server size.
Even if OLS would take to read all the configs 10seconds - the 3 second delay is still there.

Direct Systemd script would look cleaner, because lots of various waits and kills in a helper script pushes the idea that the software cannot handle those actions reliably by itself.
OLS process can deal the reloads/queues/signals internally instead of artificially delaying static amount of time in external script.
We did try to stress test using loop kill/reload commands, no side effects were observed so far.