line of sendmail log output missing?
Hi, I recently switched from syslogd to syslog-ng on several servers running CentOS. While running syslogd, a usual mail delivery appeared in /var/log/maillog as follows: Apr 22 04:11:07 ws01 sendmail[32181]: l3M8B71l032181: from=<someuser@someremote.domain>, size=2361, class=0, nrcpts=1, msgid=<001901c784c6$9688fea0$018ab484@maison9tm8hfuv>, proto=ESMTP, relay=root@localhost Apr 22 04:11:07 ws01 sendmail[32179]: l3M8Av5T032164: to=<domain_support@somelocal.domain>, delay=00:00:04, xdelay=00:00:00, mailer=virthostmail, pri=121926, relay=somelocal.domain, dsn=2.0.0, stat=Sent (l3M8B71l032181 Message accepted for delivery) Apr 22 04:11:07 ws01 spamd[24594]: spamd: connection from localhost.localdomain [127.0.0.1] at port 50252 Apr 22 04:11:07 ws01 spamd[24594]: spamd: setuid to domain_admin@somelocal.domain succeeded Apr 22 04:11:07 ws01 spamd[24594]: spamd: processing message <001901c784c6$9688fea0$018ab484@maison9tm8hfuv> for domain_admin@somelocal.domain:22003 Apr 22 04:11:08 ws01 spamd[24594]: spamd: identified spam (18.5/4.0) for domain_admin@somelocal.domain:22003 in 1.3 seconds, 2646 bytes. Apr 22 04:11:08 ws01 spamd[24594]: spamd: result: Y 18 - BAYES_99,HELO_DYNAMIC_IPADDR2,HELO_DYNAMIC_SPLIT_IP,HTML_MESSAGE,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL scantime=1.3,size=2646,user=domain_admin@somelocal.com,uid=22003,required_score=4.0,rhost=localhost.localdomain,raddr=127.0.0.1,rport=50252,mid=<001901c784c6$9688fea0$018ab484@maison9tm8hfuv>,bayes=1,autolearn=spam Apr 22 04:11:08 ws01 spamd[4109]: prefork: child states: BI Apr 22 04:11:08 ws01 spamd[4109]: spamd: handled cleanup of child pid 24594 due to SIGCHLD Apr 22 04:11:08 ws01 spamd[4109]: spamd: server successfully spawned child process, pid 32189 Apr 22 04:11:08 ws01 spamd[4109]: prefork: child states: II Apr 22 04:11:08 ws01 sendmail[32182]: l3M8B71l032181: to=domain_admin, delay=00:00:01, xdelay=00:00:01, mailer=local, pri=32547, dsn=2.0.0, stat=Sent Now, after replacing syslogd with syslog-ng, the last line showing the delivery by the local mailer ( in this case, procmail ) is absent from the log files. I have made sure that levels info through emergency are specified for facility mail, and have also checked to see if this message was showing up under any other facility ( although I have not explicity defined the levels for all facilities ). I am rather stumped about where this line of log output is going. Any suggestions would be greatly appreciated. -- We're all in this together.
Hi,
I recently switched from syslogd to syslog-ng on several servers running CentOS. While running syslogd, a usual mail delivery appeared in /var/log/maillog as follows:
Apr 22 04:11:07 ws01 sendmail[32181]: l3M8B71l032181: from=<someuser@someremote.domain>, size=2361, class=0, nrcpts=1, msgid=<001901c784c6$9688fea0$018ab484@maison9tm8hfuv>, proto=ESMTP, relay=root@localhost Apr 22 04:11:07 ws01 sendmail[32179]: l3M8Av5T032164: to=<domain_support@somelocal.domain>, delay=00:00:04, xdelay=00:00:00, mailer=virthostmail, pri=121926, relay=somelocal.domain, dsn=2.0.0, stat=Sent (l3M8B71l032181 Message accepted for delivery) Apr 22 04:11:07 ws01 spamd[24594]: spamd: connection from localhost.localdomain [127.0.0.1] at port 50252 Apr 22 04:11:07 ws01 spamd[24594]: spamd: setuid to domain_admin@somelocal.domain succeeded Apr 22 04:11:07 ws01 spamd[24594]: spamd: processing message <001901c784c6$9688fea0$018ab484@maison9tm8hfuv> for domain_admin@somelocal.domain:22003 Apr 22 04:11:08 ws01 spamd[24594]: spamd: identified spam (18.5/4.0) for domain_admin@somelocal.domain:22003 in 1.3 seconds, 2646 bytes. Apr 22 04:11:08 ws01 spamd[24594]: spamd: result: Y 18 - BAYES_99,HELO_DYNAMIC_IPADDR2,HELO_DYNAMIC_SPLIT_IP,HTML_MESSA GE,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL > scantime=1.3,size=2646,user=domain_admin@somelocal.com,uid=220 03,required_score=4.0,rhost=localhost.localdomain,raddr=> 127.0.0.1,rport=50252,mid=<001901c784c6$9688fea0$018ab484@mais on9tm8hfuv>,bayes=1,autolearn=spam Apr 22 04:11:08 ws01 spamd[4109]: prefork: child states: BI Apr 22 04:11:08 ws01 spamd[4109]: spamd: handled cleanup of child pid 24594 due to SIGCHLD Apr 22 04:11:08 ws01 spamd[4109]: spamd: server successfully spawned child process, pid 32189 Apr 22 04:11:08 ws01 spamd[4109]: prefork: child states: II Apr 22 04:11:08 ws01 sendmail[32182]: l3M8B71l032181: to=domain_admin, delay=00:00:01, xdelay=00:00:01, mailer=local, pri=32547, dsn=2.0.0, stat=Sent
Now, after replacing syslogd with syslog-ng, the last line showing the delivery by the local mailer ( in this case, procmail ) is absent from the log files. I have made sure that levels info through emergency are specified for facility mail, and have also checked to see if this message was showing up under any other facility ( although I have not explicity defined the levels for all facilities ).
I am rather stumped about where this line of log output is going. Any suggestions would be greatly appreciated.
Hi, if you suspect a facility/severity problem then using a fallback log at the end of the configuration might help you, like this: log { source(s_all); destination(d_fallback); flags(fallback); }; Syslog-ng can cache log messages in memory so it might be the case that the logs gets written with a small delay. Without seeing your actual configuration it's hard to help you further.. Sendmail isn't modular so when an openlog was successful (and it was because you see messages from sendmail) then you're unlikely to hit any log socket connection number limits which sometimes happen - but this will get logged by syslog-ng if you use the internal() source. Regards, Sandor -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
On 04May2007 03:39PM (+0100), Geller, Sandor (IT) wrote:
Hi, if you suspect a facility/severity problem then using a fallback log at the end of the configuration might help you, like this:
log { source(s_all); destination(d_fallback); flags(fallback); };
Syslog-ng can cache log messages in memory so it might be the case that the logs gets written with a small delay. Without seeing your actual configuration it's hard to help you further.. Sendmail isn't modular so when an openlog was successful (and it was because you see messages from sendmail) then you're unlikely to hit any log socket connection number limits which sometimes happen - but this will get logged by syslog-ng if you use the internal() source.
Regards,
Sandor
Thanks. I'm not seeing anything in the fallback log at all. I'm also not seeing any errors or dropped messages in syslog-ng's log output. Attached is my syslog-ng.conf. Perhaps you may spy something there.
On Fri, 2007-05-04 at 10:25 -0400, Centyx Centalix wrote:
Hi,
I recently switched from syslogd to syslog-ng on several servers running CentOS. While running syslogd, a usual mail delivery appeared in /var/log/maillog as follows:
Apr 22 04:11:07 ws01 sendmail[32181]: l3M8B71l032181: from=<someuser@someremote.domain>, size=2361, class=0, nrcpts=1, msgid=<001901c784c6$9688fea0$018ab484@maison9tm8hfuv>, proto=ESMTP, relay=root@localhost Apr 22 04:11:07 ws01 sendmail[32179]: l3M8Av5T032164: to=<domain_support@somelocal.domain>, delay=00:00:04, xdelay=00:00:00, mailer=virthostmail, pri=121926, relay=somelocal.domain, dsn=2.0.0, stat=Sent (l3M8B71l032181 Message accepted for delivery) Apr 22 04:11:07 ws01 spamd[24594]: spamd: connection from localhost.localdomain [127.0.0.1] at port 50252 Apr 22 04:11:07 ws01 spamd[24594]: spamd: setuid to domain_admin@somelocal.domain succeeded Apr 22 04:11:07 ws01 spamd[24594]: spamd: processing message <001901c784c6$9688fea0$018ab484@maison9tm8hfuv> for domain_admin@somelocal.domain:22003 Apr 22 04:11:08 ws01 spamd[24594]: spamd: identified spam (18.5/4.0) for domain_admin@somelocal.domain:22003 in 1.3 seconds, 2646 bytes. Apr 22 04:11:08 ws01 spamd[24594]: spamd: result: Y 18 - BAYES_99,HELO_DYNAMIC_IPADDR2,HELO_DYNAMIC_SPLIT_IP,HTML_MESSAGE,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL scantime=1.3,size=2646,user=domain_admin@somelocal.com,uid=22003,required_score=4.0,rhost=localhost.localdomain,raddr=127.0.0.1,rport=50252,mid=<001901c784c6$9688fea0$018ab484@maison9tm8hfuv>,bayes=1,autolearn=spam Apr 22 04:11:08 ws01 spamd[4109]: prefork: child states: BI Apr 22 04:11:08 ws01 spamd[4109]: spamd: handled cleanup of child pid 24594 due to SIGCHLD Apr 22 04:11:08 ws01 spamd[4109]: spamd: server successfully spawned child process, pid 32189 Apr 22 04:11:08 ws01 spamd[4109]: prefork: child states: II Apr 22 04:11:08 ws01 sendmail[32182]: l3M8B71l032181: to=domain_admin, delay=00:00:01, xdelay=00:00:01, mailer=local, pri=32547, dsn=2.0.0, stat=Sent
Now, after replacing syslogd with syslog-ng, the last line showing the delivery by the local mailer ( in this case, procmail ) is absent from the log files. I have made sure that levels info through emergency are specified for facility mail, and have also checked to see if this message was showing up under any other facility ( although I have not explicity defined the levels for all facilities ).
I am rather stumped about where this line of log output is going. Any suggestions would be greatly appreciated.
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
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? Thanks for all of your input!
I believe I have found the answer. Further examination of the old syslogd init script showed that at the daemon's startup the chroot log devices were being linked to the device in /home/virtual/FILESYSTEMTEMPLATE. This step is obviously not taking place now. Thanks again for all of your help. On 04May2007 04:12PM (-0400), Centyx Centalix wrote:
/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?
Thanks for all of your input!
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html
-- If we don't try, we don't do. And if we don't do, why are we here...?
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
participants (3)
-
Balazs Scheidler
-
Centyx Centalix
-
Geller, Sandor (IT)