All of lore.kernel.org
 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: Sun, 22 Jun 2003 06:31:56 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-105626399225942@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-105613022514760@msgid-missing>

On Saturday 21 June 2003 18:11, Adrien Beau wrote:
> 
> > 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.

It quickly turned out that this was a wrong idea, since the scripts
are started at the same time. It only makes things worse, since the
the lockfile then disappears while a script is sleeping.

It doesn't matter any more, though, since I have found a solution to
this problem. I tried to find what made the test fail. It turns out
that

  expr $currenttime '-' $timestamp '<' $MAX_LOCK_AGE

returns 1 to stdout, which means that indeed, expr thinks that 0 or 1
are less than 60. The bug is that, when run in "normal" conditions,
at a few seconds interval, the above command has an exit status of 0,
but when run in "stress" conditions, at a few hundredth of seconds
interval, its exit status is 1. That's just weird (a bug in the kernel
or glibc, or what?), but that can be worked around. I ended up using

  [ `expr $currenttime '-' $timestamp` -lt $MAX_LOCK_AGE ]

instead, which works fine.

-- 
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-22  6:31 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
2003-06-22  6:31 ` Adrien Beau [this message]
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-105626399225942@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.