OpenLiteSpeed won't start: fix lsws failed, inactive, masked and segfault errors

When every site on a CyberPanel server goes down at once, OpenLiteSpeed is usually the reason. The trap is that systemctl restart lsws fixes the easy cases and hides the hard ones. This guide walks through the states and causes in the order that finds the real problem fastest.

Read the state correctly

systemctl is-active lsws     # active | inactive | failed | activating
systemctl is-enabled lsws    # enabled | disabled | masked

State	Meaning	Action
inactive + no errors in journal	Simply not running	systemctl start lsws
disabled	Will not start on boot	systemctl enable lsws
masked	Deliberately locked	systemctl unmask lsws && systemctl enable --now lsws (only if you know why it was masked)
failed	Tried to start and crashed	Do not restart blindly. Read the journal, below.
activating for more than 30s	Stuck starting	Wait, re-check, then treat as failed

Disk and memory first

df -h / ; df -i /
free -m
dmesg -T | grep -iE "out of memory|killed process|segfault" | tail

OpenLiteSpeed needs to write /tmp/lshttpd/lshttpd.pid and its sockets. With no space or no inodes it fails silently. If the disk is above 95%, clean it safely before any other step, or any package you reinstall may be corrupt too.

The six real causes, and their fixes

journalctl -xeu lsws -n 60 --no-pager
tail -n 80 /usr/local/lsws/logs/error.log
/usr/local/lsws/bin/openlitespeed -t     # config test

1. Port 80 or 443 is taken

ss -ltnp 'sport = :80'
ss -ltnp 'sport = :443'

If you see apache2, httpd, nginx or caddy, another web server grabbed the port (often after a package pulled Apache in as a dependency). Make sure you did not put it there on purpose, then:

systemctl disable --now apache2 2>/dev/null || systemctl disable --now httpd 2>/dev/null
systemctl disable --now nginx 2>/dev/null
systemctl restart lsws

2. Stale PID file

After a crash or an unclean reboot the old PID file can block the new process.

rm -f /tmp/lshttpd/lshttpd.pid
mkdir -p /tmp/lshttpd && chown nobody:nogroup /tmp/lshttpd   # AlmaLinux: nobody:nobody
systemctl start lsws

3. Invalid configuration

openlitespeed -t or error.log reports a parse error, often in a vhost conf edited by hand or half-written by a failed CyberPanel operation. Back up the config directory before touching it:

cp -a /usr/local/lsws/conf /root/lsws-conf-backup-$(date +%F)

Then fix the file the log names, or temporarily comment out the broken vhost in httpd_config.conf, start lsws, and recreate that vhost from CyberPanel.

4. A vhost's SSL files are missing

If a site's certificate or key file was deleted or a renewal failed half-way, OpenLiteSpeed refuses to start the listener. Find the missing files:

grep -hE "keyFile|certFile" /usr/local/lsws/conf/vhosts/*/vhost.conf | awk '{print $2}' | while read f; do [ -f "$f" ] || echo "MISSING $f"; done

Generate a temporary self-signed pair in that path so the server comes up, then issue a real certificate from CyberPanel:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -subj "/CN=localhost" \
  -keyout /path/privkey.pem -out /path/fullchain.pem
systemctl restart lsws

5. Out of memory

dmesg shows Killed process ... (openlitespeed) or (lsphp). Get it back up, then give the server room:

sync; echo 3 > /proc/sys/vm/drop_caches
systemctl restart lsws
# if there is no swap:
fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile
echo "/swapfile none swap sw 0 0" >> /etc/fstab

Then reduce PHP children in the lsphp external app settings in the WebAdmin console, or move to a larger plan; swap is a cushion, not a cure.

6. Corrupt binary (segfault)

Covered in detail next, because it is the one people get wrong.

The segfault case in detail

The journal shows Main process exited, code=killed, status=11/SEGV or error.log is empty because the process dies before logging. Check the binary:

file /usr/local/lsws/bin/openlitespeed
ls -la /usr/local/lsws/bin/
/usr/local/lsws/bin/openlitespeed -v

A 0-byte file, data instead of ELF 64-bit, or -v itself segfaulting confirms it. The binary was most likely written while the disk was full during an unattended package update. The fix is a package reinstall; it replaces the binaries and leaves /usr/local/lsws/conf alone. Back the config up anyway, it costs nothing:

cp -a /usr/local/lsws/conf /root/lsws-conf-backup-$(date +%F)

# Ubuntu
apt-get clean && apt-get install --reinstall -y openlitespeed

# AlmaLinux / Rocky
dnf clean all && dnf reinstall -y openlitespeed

systemctl restart lsws

If the package manager cannot find openlitespeed, the LiteSpeed repository was removed. Re-add it (Ubuntu: wget -O - https://repo.litespeed.sh | bash; the same script works on AlmaLinux) and run the reinstall again.

Verify

systemctl is-active lsws
ss -ltnp 'sport = :80' | grep -c litespeed
for d in $(ls /usr/local/lsws/conf/vhosts/); do
  printf "%-30s " "$d"; curl -sk -o /dev/null -w "%{http_code}\n" -H "Host: $d" https://127.0.0.1/
done

Active, listening, and every site answering 200/301/302. If lsws is active but a site answers 503, the problem has moved to that site's PHP backend; see website 503s.