First, the problem, so I at least don't lose sight of it:
Johan Vromans recently wrote this:
I agree that "the optimal solution" is very hard to implement. But the
current locking scheme has an annoying side-effect. For example, I run
a fetchmail daemon to fetch my email from a remote site. Occasionally,
I need to fetch some email from another pop host. To do this, I first
need to stop the background fetchmail, run the dedicated fetchmail,
and then restart the background fetchmail. This is annoying, since
fetching email from one system does not interfere with a fetch from
another host.
Rob MacGregor wrote:
From: "Eric S. Raymond" <esr(_at_)snark(_dot_)thyrsus(_dot_)com>
On one level this is an implementation problem -- I use the lockfile
as a rendezvous where foreground instances of fetchmail can find the
PID of the unique background instance. On another level it's more
fundamental -- without locking, there is not necessarily a unique
background instance at all. How would we know which one to signal?
Why not use /var/run/fetchmail.pid - something many applications use. If
you want to keep it unique per user then /var/run/fetchmail-<username>.pid
for anybody other than root.
/var/run is (should be) writable by root only.
Also, that would still give only one fetchmail daemon per
user... though I would argue that is a good thing. It makes sense to
allow only one daemon, at least for each user.... which takes us back
to home directories.
(a) leave the present locking alone in order to keep -q working everywhere.
(b) scrap client-side locking entirely -- multiple concurrent
instances would be possible, but -q would stop working.
Not ideal unless you can come up with some other way to cleanly shutdown all
instances of fetchmail. Of course, if kill -HUP does that, then that's ok.
kill -HUP should restart the daemon, not kill it. Standard daemon
behavior.
How about a combination of these two? Keep the locking (in some form)
for daemon fetchmails, but make non-daemon fetchmails ignore the
locks. This would seem to solve Johan's problem. Keep the current -q
behavior (that's not an invocation that should ignore the lock) since
it's explicitly about killing a running daemon.
The hard part is a bare fetchmail command with a daemon running --
should it awaken the daemon as it does now, or start a non-daemon
fetch? One possibility is a new -W switch for doing a wakeup.
Another is to keep current behavior unless a specific host to fetch
from is specified on the command line. I like the latter solution
since it's more backward-compatible.
Basically, I propose changing the semantics of the lockfile so that
instead of trying to lock access to the remote server, we lock the
daemon.
(c) do the funky chicken with shared memory -- multiple concurrent
instances would be possible, and -q would mostly work but might
break on some platforms.
The definition of "some platforms" would be interesting here. Mind you, I
think it might help if you had a list of what platforms people use fetchmail
on and whether those platforms support shared memory.
This seems like the "cleanest" solution where it works, but it all depends
on how much it breaks. Would there be any way to to (c) on supported
platforms and (b) otherwise?
I disagree that this would be the cleanest solution. It sound like it
would be difficult to get all the bugs out.
--
==============================| "A microscope locked in on one point
Rob Funk <rfunk(_at_)funknet(_dot_)net> |Never sees what kind of room that
it's in"
http://www.funknet.net/rfunk | -- Chris Mars, "Stuck in Rewind"