Re: [gentoo-user] Re: weird cron mail problem: basically solved
090106 Harry Putnam wrote: Philip Webb purs...@ca.inter.net writes: 090106 Willie Wong wrote: you may want to change the root line to root=purslow, so the mail gets sent to purslow instead of postmaster (which according to /etc/mail/aliases becomes root again). That doesn't work, but adding ' /dev/null' or '-s' in crontab does. The latter seems simpler, so that's what I've done. It doesn't explain why the problem suddenly arose last Sunday after I made a simple editing change in .fetchmailrc nothing like this had happened before with the same crontabssmtp.conf : perhaps there's an obscure bug, but the irritating problem has been resolved I have other jobs today. I don't see the actual change made to fetchmailrc. The problem started after I commented the line 'set logfile /home/purslow/Mail/logfile'. You can introduce an unprintable CHAR into a *.rc file and not be able to see it. you might want to use vim to check each line. You can hit the el (l) lowercase on each line to expose most kinds of unprintable char: 1) : 2) l 3) enter Then the line appears in the command area with any unprintable chars, I tried that, but there's no sign of an unprintable character. Do you control this machine ? Yes, I built it no-one else ever gets near it. Nearly all of the problem seems clear now, so for the record: the basic problem arose because when I went over to downloading mail via a user cronjob for security, I didn't add '-s' to 'fetchmail'; as a result, Fetchmail was writing several lines to ~/Mail/logfile every 5 min with the obvious result that the file got very big; frustrated by this, I took a quick look the simple fix seemed to be to remove the line in ~/.fetchmailrc which defined it (see above); as soon as I did this (early Sun), msgs starting arriving in my spamtrap mysteriously originating at 'r...@myisp'; moreover, other lines continued to be added to logfile , which I realised came from Procmail, so I altered ~/.procmailrc to suppress those (successfully); to try to stop the mail msgs, I restored the original ~/.fetchmailrc , but that had no effect, at which point I sought help via this list. The correct procedure is to stop the msgs at source with 'fetchmail -s', so having done that, the real-life irritation has gone away. It's also clear how the rogue e-mails arose: when a cronjob ouputs msgs, they are handled by Cron itself (see 'man cron'), not eg by Fetchmail, so Cron sent them to 'root', which led all around the haystack. What remains unclear is why restoring the original ~/.fetchmailrc didn't cause the msgs to be sent again to ~/Mail/logfile , but that's not important enough to take more of my time. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] Re: weird cron mail problem
090105 Harry Putnam wrote: Philip Webb purs...@ca.inter.net writes: The problem originated 090104 c0520 , when I edited ~/.fetchmailrc to delete the reference to a logfile. However, attempts to restore the STATVS QVO ANTE have failed: I've restored the previous version of .fetchmailrc without success I've remerged Fetchmail, rebooted then run fetchmailconf , but the crazy mails continue to appear every 5 min in my inbox. I think that looks like normal cron mail... Looks like you may have once had a redirect to `/dev/null' in the crontab line and inadvertently removed it. No, I have never touched the cron part of it since installing 0710xx . It looks to me as if Fetchmail reacts badly if you change anything by hand in ~/.fetchmailrc : I did exactly that without any problem when I changed ISPs 0809xx, but I also find it odd that Fetchmail is sending the mail to Uniserve, but not to my U Toronto e-ddress, which is also in .fetchmailrc . I have a few ideas of things to try today will try yours too (thanks). Any suggestions from others are very welcome. My fetchmail line in crontab: */15 * * * * /usr/bin/fetchmail -f /home/reader/.fetchmailrc /dev/null 21 Note the difference with yours: */5 * * * * /usr/bin/fetchmail Not redirect in yours but note that I dump any output to /dev/null You may first want to just say `cmd /dev/null' , so that any errors are still send to you but once its working smoothly you can add 21 like `cmd /dev/null 21', so that both stderr and stdout go to dev/null I think you can also do the same thing like this `cmd /dev/null -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-user] Re: weird cron mail problem
Philip Webb purs...@ca.inter.net writes: 090106 Willie Wong wrote: you may want to change the root line to root=purslow, so the mail gets sent to purslow instead of postmaster (which according to /etc/mail/aliases becomes root again). That doesn't work, but adding ' /dev/null' or '-s' in crontab does. The latter seems simpler, so that's what I've done. It doesn't explain why the problem suddenly arose last Sunday after I made a simple editing change in .fetchmailrc nothing like this had happened before with the same crontabssmtp.conf : perhaps there's an obscure bug, but the irritating problem has been resolved I have other jobs today. Thanks for the helpful advice (smile). Looking back thru the thread I don't see the actual change made to fetchmailrc. Maybe just blind. From my experience fetchmail is a very robust (non buggy) and easily configured tool. At least for my simple usage. It's the only config I can think of that is edited much like you might talk to friend while walking along. Something that happens from time to time is introducing an unprintable CHAR into a *.rc file and not being able to see it. I'm not sure if fetchmail would respond poorly to that. If there is any chance of that; you might want to use vim to check each line. You can hit the el (l) lowercase, on each line to expose most kinds of unprintable char. It takes 3 key strokes to show the line. 1) : 2) l 3) enter Then the line appears in the command area along with any unprintable chars, As Willie mentioned the mail mta is capable of rewriting stuff in its configurations. Do you control this machine? Sorry if you've already covered that. Another unlikely thing that can catch you ... happened to me on a remote account I didn't control. The machine underwent some kind of mishap that required serious backup effort replacing all us users files from backups. Turned out the backups were pretty old and further I missed the notification about the mishap... the next thing I knew lots of strange things began to happen. Some of my older configurations were re-introduced in place of things I had changed due to new circumstances.
[gentoo-user] Re: weird cron mail problem
Philip Webb purs...@ca.inter.net writes: Also, have you updated either cron or fetchmail recently? The problem originated 090104 c0520 , when I edited ~/.fetchmailrc to delete the reference to a logfile. However, attempts to restore the STATVS QVO ANTE have failed: I've restored the previous version of .fetchmailrc without success I've remerged Fetchmail, rebooted then run fetchmailconf , but the crazy mails continue to appear every 5 min in my inbox. I think that looks like normal cron mail... Looks like you may have once had a redirect to `/dev/null' in the crontab line and inadvertently removed it. My fetchmail line in crontab: */15 * * * * /usr/bin/fetchmail -f /home/reader/.fetchmailrc /dev/null 21 Note the difference with yours: */5 * * * * /usr/bin/fetchmail Not redirect in yours but note that I dump any output to /dev/null You may first want to just say `cmd /dev/null' So that any errors are still send to you but once its working smoothly you can add 21 like `cmd /dev/null 21' so that both stderr and stdout go to dev/null I think you can also do the same thing like this `cmd /dev/null
