"Bill Greganti" <t20030101(_at_)greganti(_dot_)com> writes:
-----Original Message-----
From: fetchmail-friends-admin(_at_)lists(_dot_)ccil(_dot_)org
[mailto:fetchmail-friends-admin(_at_)lists(_dot_)ccil(_dot_)org] On Behalf
Of
Matthias Andree
Sent: Sunday, April 17, 2005 12:36 PM
To: fetchmail-friends(_at_)lists(_dot_)ccil(_dot_)org
Subject: Re: [fetchmail]Fetchmail daemon mode
Actually, the daemon runs as the user fetchmail by default, not as
root.
Is this something you're doing explicitly? Just running fetchmail as
root user will not drop privileges.
That's seems to be the default for the Debian package. I haven't
changed anything.
Then the Debian guys must've poked the code. I don't have a "fetchmail"
user on my non-Debian system.
Please don't assume $DISTRIBUTOR's behavior is the same as default.
The would require me to make a cron job for each user that uses
fetchmail, unless I'm missing some clever way to automate this.
I wonder if some of the service dispatchers can handle such tasks, there
are cron variants, runit, uoschedule, but I don't know about their
capabilities.
You don't want to do that on very old operating systems or if you're
short on memory.
The machine is an Athlon XP 2200 with 1GB of memory. I guess
I'm just a little too used to working with Windows machines where
10 processes running crashes the machine. :)
If you get those 10 processes up before work is over or you need to go
to bed. :)
A server that causes timeouts delays mail for all other
users, with many
servers to poll up to the point where a single run of that single run
control file takes longer to process than your users are willing to
accept.
Doh! With thousands of users that could pose a real problem in the
future. It becomes too likely that one server will gum up the whole
process at some point.
Indeed, which is why separate configuration files, one per user, or
grouped by upstream server at most, are my recommendation.
--
Matthias Andree