[Libwebsockets] logrotate puzzle

Andy Green andy at warmcat.com
Tue Apr 26 09:33:53 CEST 2016

Hi -

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 mailing list