severity 311812 grave
#rationale: data loss
tags 311812 + etch lenny sid
thanks
This bug introduce a serious risk of loosing important log data, which
is - especially for a MTA - not acceptable. Asking people to restart
postfix after reloading syslog is a *stupid* workaround, which also
results in the loss of log entries (during the time when syslog is
restarted but postfix not yet). The only working, but not less ugly,
workaround is to stop postfix first, then reload/restart syslog, and
start postfix again.
It seems you're just doing nothing to fix this bug, this behavior is a
shame as you're ruining the image of postfix as the best MTA we have in
Debian. If you really think the bug should be fixed in sysklogd -
where's the open grave bug in sysklogd, syslog-ng and other syslog
daemons which block *this* bug?
There're a few ways to get a syslog socket into the chroot, like
- using syslog-ng: my suggested way, but depending on a syslog daemon is
not nice.
- using bind mounts: not available on older kernels, also a bind mount
needs to be recreated after re{loading,starting} the syslog daemon
None of the ways is an optimal way for the common user, so my suggestion
is to write a little daemon which does nothing but providing a syslog
socket in the chroot and relying messages to the real syslog daemon,
like a proxy for sockets. Due to the flexibility of postfix's master.cf
the daemon could just be deactivated if a user prefers to have a real
syslog daemon dropping it's socket in there.
Best regards,
--
Bernd Zeimetz
<[EMAIL PROTECTED]> <http://bzed.de/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
