The access log is frozen at some date; the file sits there, its size never changes, and the error log says nothing. The site keeps working. What you lose is not just visibility — everything that depends on those logs quietly stops too.
The OpenLiteSpeed master process starts as root, but the workers that serve requests drop to an unprivileged user (commonly nobody or lsadm). It is that unprivileged process which opens the log file. If the log directory is mode 750 and owned by someone else, the worker cannot open it — and does not report this as an error, it simply stops writing. The problem also recurs after log rotation: if the new file is created with the wrong ownership, logging never resumes. The fix is to align the log directory's ownership and mode with the user OpenLiteSpeed actually runs as.
You open the access log and the last line is weeks old. The site is up, visitors are arriving, and nothing is being appended. The error log offers no clue — often because the error log lives in the same directory and is not being written either.
This failure is particularly deceptive because nothing looks broken. The server is healthy, pages load, monitoring is green. You have simply gone blind.
OpenLiteSpeed applies privilege separation: the master process starts as root so it can bind privileged ports, then drops the request-handling processes to an unprivileged user. The log file is opened and written by that second group.
In panel installations the log directory is often owned by the site user or by root, with mode 750. That means "owner may read, write and enter; group may read and enter; others may do nothing". If the OpenLiteSpeed worker user is neither the owner nor in the group, it cannot even enter the directory.
A log file that cannot be opened is not a fatal condition for OpenLiteSpeed. The server keeps serving requests and drops the record. That design choice is sensible — a site should not go down over logging — but it makes diagnosis harder.
To set the right permissions you first need to know who writes. The answer is in the main configuration:
grep -E '^user|^group' /usr/local/lsws/conf/httpd_config.confYou can confirm from the running processes too; the first line is the master (root), the rest are workers:
ps -eo user,group,comm | grep -E 'litespeed|lshttpd'Put the current state of the log directory next to it:
ls -la /home/example.com/logs/If the directory owner differs from the worker user and the mode is 750, you have your cause.
The cleanest approach is to give the directory to the group OpenLiteSpeed runs as and grant that group write access — solving the problem without opening it to everyone:
chgrp nogroup /home/example.com/logs
chmod 770 /home/example.com/logsFix ownership on the existing files too; a correct directory mode does not help if the old file itself is unwritable:
chown nobody:nogroup /home/example.com/logs/*.log
/usr/local/lsws/bin/lswsctrl restartAfter the restart, send a request and confirm that records are actually flowing — do not assume:
curl -sS -o /dev/null https://example.com/
tail -2 /home/example.com/logs/example.com.access_logThis is the sneaky part. You fix the directory mode, believe the problem is solved, and a few days later logging stops again. The reason is that rotation creates a new file with the wrong ownership.
The rotation configuration has to state explicitly who the new file belongs to:
create 0640 nobody nogroupIf you use OpenLiteSpeed's own rollingSize setting it creates the file itself and this problem does not arise. Confusion begins where external logrotate and internal rotation fight over the same file: pick one, do not run both.
Losing the log is annoying on its own, but the real cost is everything downstream. When fail2ban finds no lines to read it raises no error — it simply bans nobody. The jail shows as active, the status output looks healthy, and the ban counter stays at zero.
fail2ban-client status wordpress-olsYou may be seeing "Currently failed: 0, Total banned: 0" not because there is no brute force traffic, but because the log cannot be read. On a site with real traffic that number staying at zero for long is not normal; check that logs are flowing.
The same applies to traffic statistics, error tracking and security auditing. When you inherit a server, one of the first things to check is whether the logs are actually from today.
Silent failures cost more than loud ones, because you do not know they exist until you decide to look. Log directory permissions are the textbook case: a single wrong chmod disables both your visibility and the security layer built on top of it, and leaves no trace anywhere. Add one line to your maintenance checklist: is the last line of the log from today?
grep -E '^user|^group' /usr/local/lsws/conf/httpd_config.confchgrp nogroup logs && chmod 770 logs plus file ownershipcreate 0640 nobody nogrouprollingSize on the same fileMost likely the OpenLiteSpeed worker user cannot open it. The master starts as root, but request-handling processes drop to an unprivileged user; if the log directory is mode 750 and that user is neither owner nor in the group, it cannot even enter. OpenLiteSpeed does not treat this as fatal and silently drops the record.
That is log rotation. If the new file created during rotation has the wrong ownership, writing stops again. Add create 0640 nobody nogroup to the logrotate configuration. Also avoid running external logrotate and OpenLiteSpeed's own rollingSize against the same file.
Directly. When fail2ban has no log lines to read it produces no error; the jail appears active and the ban count stays at zero. On a site with real traffic that is not normal. Check that the log is flowing first, then check the filter pattern.
It would, but do not. World-writable logs let any process on the server alter or delete records, which makes the audit trail untrustworthy. The correct approach is to give the directory to the OpenLiteSpeed group and use 770.