linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Adrien Beau <adrien.beau@free.fr>
To: linux-hotplug@vger.kernel.org
Subject: Re: Hotplug bug in Linux 2.4.21?
Date: Sat, 21 Jun 2003 16:11:00 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-105621209300796@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-105613022514760@msgid-missing>

On Friday 20 June 2003 21:18, Kevin P. Fleming wrote:
> 
> Adrien Beau wrote:
> > * When two instances of the script are run at a few seconds
> > interval, the lockfile mechanism works fine (again, see for
> > example June 17th), but when three instances run at the same
> > time, the mechanism fails in an impossible manner (see the
> > log entries starting on June 20th, at 12:15pm for the first
> > occurence of this, and see the entries at 12:55:55pm for an
> > occurence with the timestamps printed in the logs).
>
> I suspect your problem is that you are using timestamps for
> this log checking, and the timestamp granularity is too coarse.

It is coarse, but it shouldn't matter: if the two timestamps are
equal, or off by one, their difference is obviously less than
60 seconds. The script should then consider there's a fresh
lockfile, and should bail out. This is what it does when two
scripts are run at a few seconds interval.

My problem is that the script manages to find that the lockfile
exists, manages to read the timestamp from the logfile, but
then somehow decides that the difference between the timestamp
and the current time is more than 60 seconds! However, as the
logfile shows, the difference is never more than 1 second.
Something weird is happening behind the scenes.

> When the USB core decides to generate hotplug events for all
> three interfaces of a device it just found, those three
> /sbin/hotplug invocations are going to happen very quickly,
> certainly within a small fraction of a second.

This is what happens indeed.

> You'll need to find some other way of knowing when a lockfile
> exists and is stale... something that can handle more than one
> process that is started at identical times (or nearly so).

Even with the very short interval between them, the scripts find
without error that the lockfile exists, and read it without error.
However, they then go to decide that 1 is greater than 60, and
*that*, I can't understand.

I'm going to put some sleep(1) at appropriate places and see if
this helps.

-- 
adrien.beau@free.fr - http://adrien.beau.free.fr/



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

  parent reply	other threads:[~2003-06-21 16:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-20 17:25 Hotplug bug in Linux 2.4.21? Adrien Beau
2003-06-20 17:51 ` Greg KH
2003-06-20 18:15 ` Duncan Sands
2003-06-20 18:44 ` Adrien Beau
2003-06-20 19:18 ` Kevin P. Fleming
2003-06-21 10:12 ` Olaf Hering
2003-06-21 15:56 ` Adrien Beau
2003-06-21 16:11 ` Adrien Beau [this message]
2003-06-22  6:31 ` Adrien Beau
2003-06-27 15:15 ` Adrien Beau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-hotplug-105621209300796@msgid-missing \
    --to=adrien.beau@free.fr \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).