[opensuse] Tearing my hear out - mail server malfunction
Hi all. I run a local mail server with a fairly standard setup: Fetchmail -> sendmail ->procmail -> spamd -> Maildir -> dovecot IMAP. Everything worked fine until around 1345 local time Sunday. Ever since then, fetchmail has been dumping all mail into /var/spool/mail/<username> and there it stays. The rest of the chain isn't firing. procmail is configured to write to a log file in my home directory (pm.log) and that is not being written. Nothing has been written to /var/log/mail since August 28th (when I upgraded to oS 11.4) so that is no help. I have tried logging out of KDE and even restarting the machine (which I rarely do - uptimes of >180 days are not uncommon) but to no avail. I'm completely stumped as to why it was working fine and then suddenly stopped with no intervention. I haven't even installed any updates in the last week or so. I'd appreciate any pointers as to where to look next. Fetchmail is working fine, as I said, but nothing gets past /var/spool/mail/<username>. When it was working fine, nothing went into this directory, let alone stayed there. What has broken and why? (Yes, I know that is an almost impossible question but at least if I knew where to look it would help). ps -eaf | grep 'mail' says: root 4501 1 0 Oct09 ? 00:00:01 sendmail: accepting connections 110 5765 1 0 18:22 ? 00:00:00 /usr/bin/fetchmail -d 90 -a -f /etc/fetchmailrc -L /var/log/fetchmail user 6023 5805 0 18:33 pts/0 00:00:00 grep mail mail 8214 1 0 Oct09 ? 00:00:00 sendmail: Queue control mail 8215 8214 0 Oct09 ? 00:00:01 sendmail: running queue: /var/spool/clientmqueue use> 17700 17663 0 Oct09 ? 00:00:00 /usr/bin/akonadi_maildir_resource --identifier akonadi_maildir_resource_0 user 17701 17663 0 Oct09 ? 00:00:00 /usr/bin/akonadi_maildispatcher_agent --identifier akonadi_maildispatcher_agent user 21579 1 0 Oct09 ? 00:00:40 /usr/bin/kmail -caption KMail user 21580 17538 0 Oct09 ? 00:00:05 kdeinit4: kio_imap4 [kdeinit] imap local:/tmp/ksocket-user/klauncherT17539.slave-socket local:/tmp/ksocket- user/kmaile21579.slave-socket user 21581 17538 0 Oct09 ? 00:00:01 kdeinit4: kio_imap4 [kdeinit] imap local:/tmp/ksocket-user/klauncherT17539.slave-socket local:/tmp/ksocket- user/kmaily21579.slave-socket Thanks in advance, Rodney. -- =================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au =================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Rodney Baker wrote:
Hi all. I run a local mail server with a fairly standard setup:
Fetchmail -> sendmail ->procmail -> spamd -> Maildir -> dovecot IMAP.
Everything worked fine until around 1345 local time Sunday. Ever since then, fetchmail has been dumping all mail into /var/spool/mail/<username> and there it stays. The rest of the chain isn't firing. procmail is configured to write to a log file in my home directory (pm.log) and that is not being written.
Nothing has been written to /var/log/mail since August 28th (when I upgraded to oS 11.4) so that is no help.
Is your syslog daemon running?
I'd appreciate any pointers as to where to look next. Fetchmail is working fine, as I said, but nothing gets past /var/spool/mail/<username>. When it was working fine, nothing went into this directory, let alone stayed there.
Where would it normally go? Any info in the fetchmail log? -- Per Jessen, Zürich (11.9°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 10 Oct 2011 19:37:02 Per Jessen wrote:
Rodney Baker wrote:
Hi all. I run a local mail server with a fairly standard setup:
Fetchmail -> sendmail ->procmail -> spamd -> Maildir -> dovecot IMAP.
Everything worked fine until around 1345 local time Sunday. Ever since then, fetchmail has been dumping all mail into /var/spool/mail/<username> and there it stays. The rest of the chain isn't firing. procmail is configured to write to a log file in my home directory (pm.log) and that is not being written.
Nothing has been written to /var/log/mail since August 28th (when I upgraded to oS 11.4) so that is no help.
Is your syslog daemon running?
Er, no. Damn! /etc/init.d/syslog restart reports: Shutting down syslog services done Starting syslog servicessyslog-ng: Error in setgid(); group='wheel', gid='10', error='Operation not permitted' startproc: exit status of parent of /sbin/syslog-ng: 1 failed Hmmm...now I've got to figure out why *that* is happening. Get syslog running and I might be closer to getting some answers from /var/log/mail. Good catch.
I'd appreciate any pointers as to where to look next. Fetchmail is working fine, as I said, but nothing gets past /var/spool/mail/<username>. When it was working fine, nothing went into this directory, let alone stayed there.
Where would it normally go? Any info in the fetchmail log?
No - nothing useful - only messages about unsecured connections to the ISP's mail server (which is not unexpected because I'm connecting via POP3 on the standard port). tail /var/log/fetchmail reports: fetchmail: Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!) fetchmail: Server certificate verification error: unable to get local issuer certificate fetchmail: This means that the root signing certificate (issued for /C=AU/ST=Western Australia/L=Cloisters Square/O=iiNet Limited/OU=Network Services/CN=*.iinet.net.au) is not in the trusted CA certificate locations, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page. fetchmail: Server certificate verification error: certificate not trusted fetchmail: Server certificate verification error: unable to verify the first certificate fetchmail: Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!) fetchmail: Server certificate verification error: unable to get local issuer certificate fetchmail: This means that the root signing certificate (issued for /C=US/O=GeoTrust, Inc./CN=RapidSSL CA) is not in the trusted CA certificate locations, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page. fetchmail: Server certificate verification error: certificate not trusted fetchmail: Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!) -- =================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au =================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 10 Oct 2011 22:55:51 Rodney Baker wrote:
On Mon, 10 Oct 2011 19:37:02 Per Jessen wrote:
Rodney Baker wrote:
Hi all. I run a local mail server with a fairly standard setup:
Fetchmail -> sendmail ->procmail -> spamd -> Maildir -> dovecot IMAP.
Everything worked fine until around 1345 local time Sunday. Ever since then, fetchmail has been dumping all mail into /var/spool/mail/<username> and there it stays. The rest of the chain isn't firing. procmail is configured to write to a log file in my home directory (pm.log) and that is not being written.
Nothing has been written to /var/log/mail since August 28th (when I upgraded to oS 11.4) so that is no help.
Is your syslog daemon running?
Er, no. Damn!
/etc/init.d/syslog restart reports: Shutting down syslog services done Starting syslog servicessyslog-ng: Error in setgid(); group='wheel', gid='10', error='Operation not permitted' startproc: exit status of parent of /sbin/syslog-ng: 1
failed
Hmmm...now I've got to figure out why *that* is happening. Get syslog running and I might be closer to getting some answers from /var/log/mail. Good catch.
OK - got syslog running again. Old (default) configurations left over from 11.2 were obviously not compatible with 11.4. With that fixed, now to check for /var/log/mail... Oct 10 23:16:32 mako.vk5ztv.ampr.org sendmail[15633]: p9ACkWrn015632: forward /home/user/.forward.mako: Group writable directory Oct 10 23:16:32 mako.vk5ztv.ampr.org sendmail[15633]: p9ACkWrn015632: forward /home/user/.forward: Group writable directory Oct 10 23:16:32 mako.vk5ztv.ampr.org procmail[15634]: Suspicious rcfile "/home/user/.procmailrc" ???? There is no .forward or .forward.mako in my home directory, so I don't know why sendmail is complaining that my home directory is group-writable (but I've fixed that anyway). The permissions on ~/.procmailrc were a bit wide too, so I've changed them to 0600 now - lets see what happens on the next mail check... So far so good - mail appears to be being delivered to ~/Maildir again (as it was before) rather than /var/spool/mail/user. It beats me why it had been working fine and suddenly decided it didn't like the permissions on my home directory and .procmailrc - but at least it appears to be fixed now. Thanks Per for pointing me in the right direction. :-) Rodney. -- =================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au =================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Rodney Baker wrote:
On Mon, 10 Oct 2011 19:37:02 Per Jessen wrote:
Rodney Baker wrote:
Hi all. I run a local mail server with a fairly standard setup:
Fetchmail -> sendmail ->procmail -> spamd -> Maildir -> dovecot IMAP.
Everything worked fine until around 1345 local time Sunday. Ever since then, fetchmail has been dumping all mail into /var/spool/mail/<username> and there it stays. The rest of the chain isn't firing. procmail is configured to write to a log file in my home directory (pm.log) and that is not being written.
Nothing has been written to /var/log/mail since August 28th (when I upgraded to oS 11.4) so that is no help.
Is your syslog daemon running?
Er, no. Damn!
/etc/init.d/syslog restart reports: Shutting down syslog services done Starting syslog servicessyslog-ng: Error in setgid(); group='wheel', gid='10', error='Operation not permitted' startproc: exit status of parent of /sbin/syslog-ng: 1
failed
Hmmm...now I've got to figure out why *that* is happening. Get syslog running and I might be closer to getting some answers from /var/log/mail. Good catch.
I've been bitten once or twice myself :-( See if /var/log/audit/audit.log might have any hints about syslog-ng.
I'd appreciate any pointers as to where to look next. Fetchmail is working fine, as I said, but nothing gets past /var/spool/mail/<username>. When it was working fine, nothing went into this directory, let alone stayed there.
Where would it normally go? Any info in the fetchmail log?
No - nothing useful - only messages about unsecured connections to the ISP's mail server (which is not unexpected because I'm connecting via POP3 on the standard port).
And the mail - where would it normally go instead of /var/spool/mail/<username>? It sounds as if fetchmail is defaulting to the latter, possibly due to an access problem (wild guessing). -- Per Jessen, Zürich (15.7°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 10 Oct 2011 23:43:37 Per Jessen wrote:
Rodney Baker wrote:
On Mon, 10 Oct 2011 19:37:02 Per Jessen wrote:
Rodney Baker wrote:
Hi all. I run a local mail server with a fairly standard setup:
Fetchmail -> sendmail ->procmail -> spamd -> Maildir -> dovecot IMAP.
Everything worked fine until around 1345 local time Sunday. Ever since then, fetchmail has been dumping all mail into /var/spool/mail/<username> and there it stays. The rest of the chain isn't firing. procmail is configured to write to a log file in my home directory (pm.log) and that is not being written.
Nothing has been written to /var/log/mail since August 28th (when I upgraded to oS 11.4) so that is no help.
Is your syslog daemon running?
Er, no. Damn!
/etc/init.d/syslog restart reports: Shutting down syslog services done Starting syslog servicessyslog-ng: Error in setgid(); group='wheel', gid='10', error='Operation not permitted' startproc: exit status of parent of /sbin/syslog-ng: 1
failed
Hmmm...now I've got to figure out why *that* is happening. Get syslog running and I might be closer to getting some answers from /var/log/mail. Good catch.
I've been bitten once or twice myself :-(
See if /var/log/audit/audit.log might have any hints about syslog-ng.
Yes, it did (but I saw your reply after I got it going). It said, type=AVC msg=audit(1318249299.372:37): apparmor="DENIED" operation="capable" parent=12038 profile="/sbin/syslog-ng" pid=12039 comm="syslog-ng" capability=6 capname="setgid" syslog-ng was trying to obey the "-g wheel" parameter set in /etc/sysconfig/syslog. I removed that parameter and then it started, but with a whole stack of warning messages about incompatible/obsolete parameters in /etc/syslog/syslog-ng.conf. Copying syslog-ng.conf.rpmnew to syslog-ng.conf fixed that and it started cleanly. Traps for young players - syslog is one of those things that you don't notice isn't running until you really need it, and for some reason I hadn't made the connection between syslog and /var/log/mail. I should have known better. I will next time. :-)
And the mail - where would it normally go instead of /var/spool/mail/<username>? It sounds as if fetchmail is defaulting to the latter, possibly due to an access problem (wild guessing).
Permissions problem actually - procmail was complaining about the permissions on .procmailrc and writing the error message to the non-running syslog daemon. :-| -- =================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au =================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (2)
-
Per Jessen -
Rodney Baker