[Libwebsockets] logrotate puzzle

Denis Osvald denis.osvald at sartura.hr
Tue Apr 26 10:27:20 CEST 2016


Hi,

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‐
        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.

Regards,

Denis


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
> 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 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?
> 
> -Andy
> _______________________________________________
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
> http://libwebsockets.org/mailman/listinfo/libwebsockets



More information about the Libwebsockets mailing list