[Libwebsockets] logrotate puzzle
denis.osvald at sartura.hr
Tue Apr 26 10:27:20 CEST 2016
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‐
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 which
lwsws truncates the log itself, rather than 'copytruncate', in order to
prevent the data loss situation described in copytruncate.
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 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?
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets