From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: Hanging udev process on nfs-mounted /dev
Date: Fri, 01 Oct 2004 10:43:47 +0000 [thread overview]
Message-ID: <1096627428.4295.114.camel@localhost.localdomain> (raw)
In-Reply-To: <415980BF.1020401@bio.ifi.lmu.de>
On Fri, 2004-10-01 at 11:43 +0200, Frank Steiner wrote:
> A general question for understanding things better: Let's assume that
> the errors indeed are caused by missing nfs locking on my /dev dir.
> It sounds reasonable that udev must be able to rely on propper locking
> for maintaining its database, so one should not expect it to work on
> a fs without locking.
> Would it be reasonable to issue a warning if udev detects it's running
> on a fs without locking (if this is possible to detect)? Or, if in
> case of missing locks the hangs cannot be prevented, udev could even
> refuse to do any work. If one gets a message from udev "No locks available.
> I will not create any devices until you give me locks" this would
> definitely help people doing stupid things like mounting /dev via NFS :-)
We should find the loop bug first. Then the alarm() should be sufficient
to prevent a hanging udev. Yes, we may include a hint in the logged
error.
We still can create nodes with udev, even with a corrupt database (I
will change the alarm() patch to act like this later). Only the remove
event will eventually fail, if a rule has set a custom name for the
device.
Other programs asking with udevinfo, may also not work correctly, but
it's better to create the node without bookkeeping than to do nothing,
I think.
Best,
Kay
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
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
next prev parent reply other threads:[~2004-10-01 10:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-28 15:18 Hanging udev process on nfs-mounted /dev Frank Steiner
2004-09-29 17:18 ` Greg KH
2004-09-29 23:39 ` Kay Sievers
2004-09-30 2:11 ` Kay Sievers
2004-09-30 6:18 ` Frank Steiner
2004-09-30 6:21 ` Frank Steiner
2004-09-30 14:07 ` Kay Sievers
2004-10-01 6:25 ` Frank Steiner
2004-10-01 7:36 ` Kay Sievers
2004-10-01 7:38 ` Frank Steiner
2004-10-01 7:55 ` Frank Steiner
2004-10-01 8:08 ` Kay Sievers
2004-10-01 9:43 ` Frank Steiner
2004-10-01 9:57 ` Kay Sievers
2004-10-01 10:43 ` Kay Sievers [this message]
2004-10-01 22:18 ` Kay Sievers
2004-10-03 21:10 ` Frank Steiner
2004-10-03 23:07 ` Kay Sievers
2004-10-04 6:15 ` Frank Steiner
2004-10-04 14:19 ` Kay Sievers
2004-10-04 14:53 ` Frank Steiner
2004-10-05 15:37 ` Kay Sievers
2004-10-06 6:06 ` Frank Steiner
2004-10-06 12:00 ` Kay Sievers
2004-10-06 12:29 ` Frank Steiner
2004-10-08 5:59 ` Frank Steiner
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=1096627428.4295.114.camel@localhost.localdomain \
--to=kay.sievers@vrfy.org \
--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).