Rob MacGregor <rob_macgregor(_at_)hotmail(_dot_)com>:
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.
All the instances of fetchmail would have to run suid in order to get
access to a common directory. Ugh...
WHAT TO DO?
I'm tossing this out for discussion. The three basic alternatives are:
(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.
(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?
That's what will happen if I condition the locking code on HAVE_SYS_SHM_H.
--
<a href="http://www.tuxedo.org/~esr/";>Eric S. Raymond</a>
Certainly one of the chief guarantees of freedom under any government,
no matter how popular and respected, is the right of the citizens to
keep and bear arms. [...] the right of the citizens to bear arms is
just one guarantee against arbitrary government and one more safeguard
against a tyranny which now appears remote in America, but which
historically has proved to be always possible.
-- Hubert H. Humphrey, 1960