locks and shutdown policy; was Re: stale lockfile on fetchmail.
peas...@shaw.ca
a> probably because fetchmail died (or ...
Which can happen if a power failure occurs
or I happen to reboot while fetchmail is
retrieving.
This strikes me as a bug. An obvious strategy
would be to remove an old lock at startup.
I know nothing about shutdown policy. Does
shutdown allow an application any leeway?
Can a second or two of delay be invoked
_via_ the xfsm-shutdown-helper?
Thanks, ... Peter E.
Desktops.OpenDoc http://carnot.yi.org/
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ron Johnson
Hash: SHA1
On 02/11/08 17:58, peas...@shaw.ca wrote:
> Andrew, Ron & others,
>
> a> probably because fetchmail died (or ...
>
> Which can happen if a power failure occurs
> or I happen to reboot while fetchmail is
> retrieving.
>
> This strikes me as a bug. An obvious strategy
> would be to remove an old lock at startup.
/tmp is cleaned out at boot. Maybe the fetchmail lockfile is
somewhere else?
> I know nothing about shutdown policy. Does
> shutdown allow an application any leeway?
> Can a second or two of delay be invoked
> _via_ the xfsm-shutdown-helper?
- --
Ron Johnson, Jr.
Jefferson LA USA
PETA - People Eating Tasty Animals
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHsPXjS9HxQb37XmcRAuBoAKCeSrM4La/3tT1bH29I4SQfJefohwCeIvnd
BDlT0srMYzk+ZYSQUfm6gq0=
=f83V
-----END PGP SIGNATURE-----
Andrew Sackville-West
> On 02/11/08 17:58, peas...@shaw.ca wrote:
> > Andrew, Ron & others,
> >
> > a> probably because fetchmail died (or ...
> >
> > Which can happen if a power failure occurs
> > or I happen to reboot while fetchmail is
> > retrieving.
> >
> > This strikes me as a bug. An obvious strategy
> > would be to remove an old lock at startup.
>
> /tmp is cleaned out at boot. Maybe the fetchmail lockfile is
> somewhere else?
>
Yeah. I think this is more likely an issue of fetchmail being killed
in a nasty way (kill -9 p<pid of fetchmail) or dying due to some other
problem.
A
Tzafrir Cohen
> Andrew, Ron & others,
>
> a> probably because fetchmail died (or ...
>
> Which can happen if a power failure occurs
> or I happen to reboot while fetchmail is
> retrieving.
>
> This strikes me as a bug. An obvious strategy
> would be to remove an old lock at startup.
fetchmail cleans that stale lock on (its) startup. That lock may be in
the user's home directory.
>
> I know nothing about shutdown policy. Does
> shutdown allow an application any leeway?
> Can a second or two of delay be invoked
> _via_ the xfsm-shutdown-helper?
fetchmail is a daemon, and thus not part of a desktop. I don't suppose
that this could be handled in the SIGKILL signal handler either.
--
Tzafrir Cohen | tza...@jabber.org | VIM is
http://tzafrir.org.il | | a Mutt's
tza...@cohens.org.il | | best
ICQ# 16849754 | | friend
Ron Johnson
Hash: SHA1
On 02/12/08 03:11, Tzafrir Cohen wrote:
> On Mon, Feb 11, 2008 at 04:58:57PM -0700, peas...@shaw.ca wrote:
>> Andrew, Ron & others,
>>
>> a> probably because fetchmail died (or ...
>>
>> Which can happen if a power failure occurs
>> or I happen to reboot while fetchmail is
>> retrieving.
>>
>> This strikes me as a bug. An obvious strategy
>> would be to remove an old lock at startup.
>
> fetchmail cleans that stale lock on (its) startup. That lock may be in
> the user's home directory.
>
>> I know nothing about shutdown policy. Does
>> shutdown allow an application any leeway?
>> Can a second or two of delay be invoked
>> _via_ the xfsm-shutdown-helper?
>
> fetchmail is a daemon, and thus not part of a desktop. I don't suppose
> that this could be handled in the SIGKILL signal handler either.
fetchmail *can* be run as a daemon. (For some reason, I decided to
run it from cron every X minutes. It runs a different divisor of 60
for myself, wife & two children.)
- --
Ron Johnson, Jr.
Jefferson LA USA
PETA - People Eating Tasty Animals
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHseDnS9HxQb37XmcRAmjMAJ4k2BUvdne4BnHQxMiCKNyQZ5NaggCfSrRs
GHB4f/mtGEMQ6hQ1D6bHb8Q=
=vyGK
-----END PGP SIGNATURE-----