[Libwebsockets] logrotate puzzle
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
> 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
>> 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?
>> Libwebsockets mailing list
>> Libwebsockets at ml.libwebsockets.org
>Libwebsockets mailing list
>Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets