On Fri, 2007-05-04 at 16:12 -0400, Centyx Centalix wrote:
On 04May2007 05:40PM (+0200), Balazs Scheidler wrote:
consistently losing a log message is strange, are you sure nothing else changed but the migration to syslog-ng? I have only seen losing messages like this when a process runs in a chroot-ed environment, with an inherited connection to /dev/log from the outside. Once the logger is restarted (regardless whether it is syslogd or syslog-ng), /dev/log gets reopened and the process stuck in a chroot cannot reconnect to /dev/log.
The solution is to open a /dev/log socket inside the chroot as well, in this way when the chrooted child loses its /dev/log connection, it can reopen it and happily log onwards.
The exact scenario I described happened with postfix but could apply to sendmail as well.
-- Bazsi
I am nearly certain that the syslog-ng migration is the culprit, as the timestamps in the logs when the change occurred ( this is happening on multiple servers ) are consistent with the times the switch was made to syslog-ng.
Furthermore, I have even tried switching back to syslogd on one of the servers to see if this log message returns, and it does. Strange, indeed.
/home/virtual/FILESYSTEMTEMPLATE/log- is used inside of many chroots, but is created as a hardlink in the chrooted environments, so I wouldn't think that this would be an issue. However, it would make sense that the local delivery logs were missing if syslog-ng were having problems w/ the log device that was used by the chroot. How may I go about troubleshooting that the log device is functioning properly and being read by syslog-ng?
You can use logger to send syslog messages to a custom log socket. Try $ logger -u "path to log device in chroot" message and see whether it gets through. I'm not sure the hard-link way would work, as syslog-ng removes and recreates log sockets as it starts. -- Bazsi