Hans Witvliet said the following on 09/24/2011 08:58 AM:
On Fri, 2011-09-23 at 21:43 -0400, Anton Aylward wrote:
James Knott said the following on 09/23/2011 04:47 PM:
Do they all have to run their own instance of fetchmail?
Yes and no. Yes they do and no its done via crontab. -- I was in the assumption that one should not run fetchmail from cron. If you want to fetch it regularly, use the "-d 1500" option, so that fetchmail runs as a deamon.
One of the problems one )might_ encounter, when using cron, is that you have the risc that one is started up, before the previous has finished, while this is avoided by using the daemon option from fetchmail.
Not a problem :-) $ crontab -l @reboot fetchmail -d 300 @hourly (fetchmail -q; sleep 5; fetchmail -d 300) >/dev/null 2>&1 Why, you ask? We've found fetchmail sometimes does strange things, is very sensitive to errors in the rc file. What it really needs is something that does a SIGUSER1 or better, something that re-reads the config file rather than just restarting the polling sequence. Or better still, detects that the rc file has changed and re-reads it. Yes I am aware that the man page says <quote> If you touch or change the ~/.fetchmailrc file while fetchmail is running in daemon mode, this will be detected at the beginning of the next poll cycle. When a changed ~/.fetchmailrc is detected, fetchmail rereads it and restarts from scratch (using exec(2); no state information is retained in the new instance). Note that if fetchmail needs to query for passwords, of that if you break the ~/.fetchmailrc file's syntax, the new instance will softly and silently vanish away on startup. </quote> But read that again and you'll see why CRON is being used to ensure robustness. Fetchmail also has problems with DNS errors at startup. I'd hope that some kind of 'dependency' mechanism such as 'systemd' will eventually address this. As for running fetchmail as a system daemon rather than a per user daemon, I think the current way of having ALL the scripts in /etc/fetchmailrc is wrong-headed. I think that the system daemon should spawn off child processes that read the per user ~/.fetchmail files and carry them out. That way the individual users can add and edit their own .fetchmail files and not compromise the system. Yes the sysadmin can still edit them as well. Nothing new there. How is this different from the system-level Apache recognising users ~/public_html and spawning of sub-processes to deal with them? As for sysloging; fetchmail produces a lot of nose but is often silent about errors. As the man page says, it sometimes 'softly and silently' vanishes. No software is perfect, sometimes we need wrappers to increase robustness. Why? In essence we don't have a 'Sysadmin on call'. If an experienced user can take care of his or her own problems in their own space we let them. But we try to make sure that they can't screw up the system for everyone else. We're not paranoid about it. We think our users are responsible people. Of course YMMD. -- If the errors of the past were good enough for our ancestors, they re good enough for us! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org