Re: Hanging udev process on nfs-mounted /dev

[Frank Steiner <fsteiner-mail@bio.ifi.lmu.de>]

Kay Sievers wrote

> It would be nice to know, if there is posssibly one process spinning at
> this time, which blocks all the other processes? Or if there is a "real"
> deadlock, where all processes are blocking in the lock call.

As far as I remember, when the udev process was running with 90% cpu time,
it was the only udev process (pgrep udev).

> You may increase the alarm()-timout to have more than 20 seconds to
> investigate this :)

I will try, but the hosts where the problem occured most frequently are
desktop clients of research asisstants. So it is not that easy to debug
it without stopping the users from working :-)


> Yeah, it does not sound very sane to do concurrent writing to the same
> file over nfs without proper locking. A local tmpfs-based /dev seems
> more appropriate for that. It should be faster anyway and there is no
> reason to store the /dev anywhere while using udev.

With debugging and logging enabled now (needed for your patch to compile),
I get lots of messages from udev broadcasted to every shell, which is
quite annoying for the users, because they get all their xterms filled:

Oct  1 05:46:50 noether udevinfo[336]: rec_read bad magic 0xd9fee666 at offsety12

And this about 15 times, every time the card reader reconnects. On the
hosts where I already replaces /dev/ with a tmpfs, those messages do
not appear at all. Apart from /dev-over-nfs vs. /dev-over-tmpfs there
are no differences between these hosts. So it seems that the nfs causes
some other problems, that tmpfs is not suffering from. I would like
to switch all hosts to tmpfs immediately, but I'm afraid I won't get
any deadlocks anymore so that we cannot do useful debugging :-)

cu,
Frank


-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *


-------------------------------------------------------
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