Bug#311812: postfix: syslog reconnection - please provide, syslogd socket in jail
Hi, has anyone thought of having a look how other distributions solved this problem? I am pretty sure some might already have solved that problem. Greetings Martin -- Martin Zobel-Helas <[EMAIL PROTECTED]> | Debian Release Team Member Debian & GNU/Linux Developer | Debian Listmaster Public key http://zobel.ftbfs.de/5d64f870.asc - KeyID: 5D64 F870 GPG Fingerprint: 5DB3 1301 375A A50F 07E7 302F 493E FB8E 5D64 F870 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311812: postfix: syslog reconnection - please provide, syslogd socket in jail
On Sun, Jan 27, 2008 at 12:01:57AM +0100, Bernd Zeimetz wrote:
> 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.
The only long-term workable solution to this bug is for syslog to allow
postfix to specify an alternate socket.
> 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?
Cloned and filed, as anyone could have done. Tracking down how to do
that took me a little while, as I've not done it previously.
> 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
3) change /etc/default/syslog to say
SYSLOG="-a /var/spool/postfix/dev/log"
and then rsync -av /dev/log /var/spool/postfix/dev/log
Note that any admin can do that, postfix may not edit the config file of
another package.
lamont
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311812: postfix: syslog reconnection - please provide, syslogd socket in jail
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]>
Bug#311812: postfix: syslog reconnection - please provide syslogd socket in jail
severity 311812 important -- On Thu, Jan 17, 2008 at 04:17:12PM +, Alexander Wirt wrote: > severity 311812 grave It's only grave if the bug is against syslogd. Syslogd doesn't provide a method for postfix to change the config file, and therefore it would be a policy violation for postfix to edit syslog's config file so that it sees things when it restarts. Once there's a way for postfix to hook up to syslogd in a policy-conformant manner, we can fix this bug. lamont -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311812: postfix: syslog reconnection - please provide syslogd socket in jail
severity 311812 grave thanks Hi, today I have been hit by this bug, which made logs from 3 days mostly useless. Asking on postfix-users about it gave me the following answer: Complain to your maintainer. The bug is that YOUR DISTRIBUTION uses Postfix chroot with an incomplete chroot jail. In particular, the jail lacks a syslogd socket that the queue manager can connect to after the syslogd process is restarted. Which is what I'm doing here. It would be nice if you could add a fix also for etch r3 oder r4. Thanks Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
