[Libwebsockets] logrotate puzzle

Andy Green andy at warmcat.com
Tue Apr 26 12:32:45 CEST 2016

On April 26, 2016 4:27:20 PM GMT+08:00, Denis Osvald <denis.osvald at sartura.hr> wrote:
>Have you looked at the following two options for logrotate?
>copy   Make  a  copy  of the log file, but don't change the original at
>       all.  This option can be used, for instance, to make a  snapshot
>       of  the  current  log  file, or when some other utility needs to
>       truncate or parse the file.  When this option is used, the  cre‐
>       ate  option  will  have  no effect, as the old log file stays in
>        place.
> copytruncate
>       Truncate the original log file to zero size in place after  cre‐

That sounds like it might work, thanks.

>       ating  a copy, instead of moving the old log file and optionally
>       creating a new one.  It can be used when some program cannot  be
>       told  to  close  its  logfile  and  thus  might continue writing
>       (appending) to the previous log file forever.  Note  that  there
>       is a very small time slice between copying the file and truncat‐
>       ing it, so some logging data might be lost.  When this option is
>       used, the create option will have no effect, as the old log file
>        stays in place.
>Perhaps it's better to combine the 'copy' option and a signal upon
>lwsws truncates the log itself, rather than 'copytruncate', in order to
>prevent the data loss situation described in copytruncate.

Alright, I'll try it... it gets me out of having to keep the credentials around just for this.

Thanks for the idea.


>On 04/26/2016 09:33 AM, Andy Green wrote:
>> 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
>> drop permissions to apache.
>> Today I noticed that logrotate had come along and renamed (archived)
>> 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
>> growing.
>> 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
>> for up to 5 minutes.
>> But this fails, because after 5 minutes, there is no way he can
>> the log file with apache permissions, he can't get back in
>> Anyone have a good idea about the Right Way to solve this?  The
>> seem to be cop out and require apache permissions level able to
>> 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
>> 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
>> get logged without having the fd open themselves).
>> Is that really the best way or some better way?
>> -Andy
>> _______________________________________________
>> Libwebsockets mailing list
>> Libwebsockets at ml.libwebsockets.org
>> http://libwebsockets.org/mailman/listinfo/libwebsockets
>Libwebsockets mailing list
>Libwebsockets at ml.libwebsockets.org

More information about the Libwebsockets mailing list