[Libwebsockets] logrotate puzzle
andy at warmcat.com
Tue Apr 26 09:33:53 CEST 2016
Logging is working well on master, pointed to /var/log/httpd/...
That dir tree is like this on my Fedora box
drwxr-xr-x. 21 root root 4096 Feb 5 08:33 /var
drwxr-xr-x. 21 root root 4096 Apr 25 03:45 /var/log
drwx------. 2 root root 4096 Apr 25 03:45 /var/log/httpd
but it's OK because we start lwsws as root, open the log file, and then
drop permissions to apache.
Today I noticed that logrotate had come along and renamed (archived) my
log... I was still logging to it okay because the inode was the same.
But if you went and looked for the original log file, logrotate had
moved it and there's nothing there. And this "archived" log would keep
I thought about it (too briefly) and added a patch that will reopen /
recreate the log file if it's been open for 5 mins. No logs will be
lost because they'll get appended to the moved / archived / renamed log
for up to 5 minutes.
But this fails, because after 5 minutes, there is no way he can reopen
the log file with apache permissions, he can't get back in /var/log/httpd.
Anyone have a good idea about the Right Way to solve this? The choices
seem to be cop out and require apache permissions level able to access
the log dir (I guess it's a good idea how it is, since it won't let
hackers with apache permission level cover their tracks), or somehow
leave a root permission fork around that redoes the logs on SIGHUP.
logrotate options for regenerating a log with apache permissions won't
help, because even if we regenerate it, we can't get back in the
/var/log/httpd/ with apache permissions.
It looks a bit messy whatever we do, since the forked process can't
nicely reopen files in the apache permissions process. It'd have to
become responsible for logging (vhosts pass logs to this root process to
get logged without having the fd open themselves).
Is that really the best way or some better way?
More information about the Libwebsockets