Request 268 was acted upon.
_________________________________________________________________________
URL: https://rt.openpkg.org/id/268
Ticket: [OpenPKG #268]
Subject: postfix package
Requestors: [EMAIL PROTECTED]
Queue: openpkg
Owner: thl
Status: open
Transaction: Correspondence added by thl
Time: Fri Oct 17 23:45:57 2003
________________________________________________________________________
> [guest - Fri Sep 19 17:03:44 2003]:
>
> > What platform, OpenPKG version, and postfix package [...]
>
> it was 20030805 versions of openpkg and postfix-2.0.13 on Solaris 9/sparc
>
> Now I've fetched and installed the newest current versions of openpkg, fsl
> and postfix and it's only a bit better - qmgr switched to the rotated log,
> but master process still has open postfix.log.0
>
Jedrzej,
I have made this letter longer than usual, because I lack the time to make it short
[Blaise Pascal]
I have examined this issue closely. OpenPKG uses a replacement for syslog(3) since the
first release [1]. In OpenPKG v1.0 we used those tiny little code fragments, they came
with every affected package. The code was limited to just writing into a file. Having
had multiple copies of the code was a maintenance nightmare. In OpenPKG v1.1 we
introduced [2] the "fake syslog library" OSSP fsl [3] which is essentially a wrapper
around OSSP l2 [4] which in turn provides a magnitude more flexibility than we had
before. In OpenPKG v1.3 we greatly increased the number of applications that use fsl.
Upon user request, at the same time we made use of fsl optional. Also the goal [5] for
OpenPKG v1.3 was to ensure that log file rotation works properly for CORE+BASE
packages which means the logs are written to predictable locations with a permissions
balanced between requirements and security with preference to security and we also
ensured that log file rotation reloads or restarts services.
I have double checked that postfix builds and installs with both fsl enabled and fsl
disabled. Please use strings(1) or what(1) to examine any binary for
presence of fsl code including debugging information. The inclusion of the
corresponding %{l_prefix}/etc/fsl/fsl.%{name} configuration file regardless of the
package being built with or without fsl is intentional, so is log file rotation in the
%{l_prefix}/etc/rd.d/rc.%{name} %daily section which is useless if anyone sticks with
vanilla syslog(3).
The capabilities of fsl v1.2 as it is shipped with OpenPKG v1.3 allows little control
about reopening a log file and no default configuration used in OpenPKG v1.3 makes use
of it. In this version the file channel received a new option called "jitter" which,
when set to "=1", causes the log file to be reopened for every write. This ensures
that a file being moved away by external means like log rotation will be reopened.
However, there is a remarkable performance penalty.
Evolution of fsl into v1.3 as it first became available in OpenPKG CURRENT
fsl-1.3.0-20031006 introduced a new feature for the file channel called "monitor"
which, when set to a non-zero n value, causes the log file to be reopened before a
write only if a check between the file that is currently open and the file that would
be opened shows a difference and that check is only triggered if the previous write
was at least n seconds ago. This means that, after an external log rotation, the
application using fsl will still have the "wrong" log file open and it might continue
to write into it for a maximum of n seconds but then it will detect the change and
reopen the file. Performance impact is negligable even with small n.
Regarding the postfix master process not releasing the logfile you found a real bug
that exists with postfix-2.0.13-1.3.1 + fsl-1.2.0-1.3.1. It goes back to [6] 20010921.
Fortunately, the master process does little, if any, logging besides startup. This is
no excuse, the issue must be fixed. If the master ever writes after log rotation,
information will be written to the outdated file on day#1 and it will be discarded on
and after day#2 because compression will create a new file and remove the one the
application has still open. I have double checked that in the latter condition only
log information will be lost, the application will not crash.
My fix in CURRENT today [7] introduces the "monitor=3600" option which ensures that
any postfix executable will not write into a rotated log for more than one hour. Keep
in mind that detection of this situation runs only before a write so unless the
application really logs something it will have the "wrong" log file open. Don't get
confused by lsof(8) output.
This new feature does no longer require an application to be reloaded after log file
rotation, so the epilog to reload/restart has vanished and the application will
continue to run with no interruption. No more service downtimes during midnight. Cool,
isn't it?
While releasing postfix as one of the first "monitor" enabled package today i want to
mention that we have tested this feature on production machines since 20030925.
We have to investigate what we should to with OpenPKG v1.3 and possibly older
releases. Options are replacing reload with restart in postfix' epilog or introduce
fsl v1.3 as an update to OpenPKG v1.3.
[1] http://cvs.openpkg.org/getfile?v=1.1&f=openpkg-src/postfix/postfix.spec
[2] http://cvs.openpkg.org/chngview?cn=3880
[3] http://www.ossp.org/pkg/lib/fsl/
[4] http://www.ossp.org/pkg/lib/l2/
[5] https://rt.openpkg.org/Ticket/Display.html?id=202 (meta ticket!)
[6] http://cvs.openpkg.org/chngview?cn=299
[7] http://cvs.openpkg.org/chngview?cn=12849
--
Thomas Lotterer
OpenPKG Developer
[EMAIL PROTECTED]
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List [EMAIL PROTECTED]
