linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Alexander E. Patrakov" <patrakov@ums.usu.ru>
To: linux-hotplug@vger.kernel.org
Subject: Re: udev taking a long time during startup
Date: Thu, 03 Aug 2006 15:51:26 +0000	[thread overview]
Message-ID: <44D21B7E.1060609@ums.usu.ru> (raw)
In-Reply-To: <1154581441.8839.33.camel@piet2.bluelane.com>

Kay Sievers wrote:
> On Wed, 2006-08-02 at 22:04 -0700, Piet Delaney wrote:
>> On Wed, 2006-08-02 at 10:57 +0200, Kay Sievers wrote:
>>> On Tue, 2006-08-01 at 00:16 -0700, Piet Delaney wrote:
>>>> We were wondering why there is a 60 second delay on our systems
>>>> from the time that the kernel releases memory and the file system 
>>>> is checked.
>>>>
>>>> I dropped into kgdb during this period and found that an init
>>>> script, S10udev in our case, was sleeping in sys_nanosleep()
>>>> or sys_wait4(). Looks like thread/process S10udev forks udevstart
>>>> which forks udev which appears to be sleeping or waiting every time
>>>> I check in on it; Seems terribly wasteful.
>>>>
>>>> udev seems to be a utility for hotplug and configured
>>>> with /etc/udev/udev.conf. Since we have no hot plug devices
>>>> I wonder if it really has to be called on every startup. On
>>>> solaris the device nodes are only re-established if you boot
>>>> with a -r option.
>>>>
>>>> I never see any children of udev, so I wonder why it's
>>>> calling wait4() and nanosleep() so often.
>>> You may check with your distro, that sounds like a broken setup. And
>>> please ask further questions on: linux-hotplug-devel@lists.sourceforge.net
>> Yep, look like LFS linux-hotplug Developers Lists might be a good idea.
>>
>> Looks like we must be using a LFS version prior to 6.1.1, as
>> we are using udev 030. I tried the latest 096 and installed it
>> in /usr/local. Was getting a bit tied on upgrading the config
>> and rule files to the new "=" convention for KERNEL and just installed
>> 030 in /usr/local so I could use the existing config and rules for now.
>>
>> Booted fine with new udev utils from src with debug going
>> to /var/log/messages. As expected I saw a lot of nanosleeps,
>> a few for what appeared to be more than 10 iterations of 10 msec.
>>
>> Since succeeding cases seemed to pass within 2 or 3 iterations of 
>> 10 msec I tried decreasing the loops (for us) to 5 iterations of 5 
>> msec. So far I don't see a problem or a substantial improvement; 
>> at least not with the tracing enabled.
>>
>> We are using the 2.6.12 thru 2.6.15 kernels and are based on the stable
>> linux from scratch (LFS) pre 6.1.1 distro; I think it's 6.1; we
>> shouldn't be running on such an old distro (support gets hard).
>>
>>         http://www.linuxfromscratch.org/
>>
>> in the future I guess we will migrate to the development LFS distro
>> which is currently useing udev-096 and linux 2.6.16.27.
>>                 
>>
>> Tonight I tried udev 096 to /usr/local/ and installed the 
>> LFS udev-config-6.2.tar rules.
>>
>> Syslog is showing some confusion with an exising daemon running:
>> ----------------------------------------------------------------
>> Aug  2 20:38:53 localhost udevsend[1794]: starting udevd daemon
>> Aug  2 20:38:53 localhost udevd[1796]: udev_config_init:
>> UDEV_CONFIG_FILE='/usr/local/etc/udev/udev.conf'
>> Aug  2 20:38:53 localhost udevd[1796]: udev_config_init:
>> udev_root='/dev'
>> Aug  2 20:38:53 localhost udevd[1796]: udev_config_init:
>> udev_rules='/usr/local/etc/udev/rules.d'
>> Aug  2 20:38:53 localhost udevd[1796]: udev_config_init: udev_log=7
>> Aug  2 20:38:53 localhost udevd[1796]: main: version 096
>> Aug  2 20:38:53 localhost udevd[1796]: init_udevd_socket: bind failed:
>> Address already in use
> 
> Ugh, disable /proc/sys/kernel/hotplug and get rid of udevsend? All that
> old stuff can't, and never worked reliably and should be disabled.
> 
> Kay

Next time, with any LFS problems, please ask the guy to upgrade to the 
latest kernel, bootscripts, udev, and udev configuration in the 
development LFS book, and ensure that old bootscripts and udev 
configuration are erased completely. Partial upgrades and leftover junk 
are not supported.

-- 
Alexander E. Patrakov

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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:[~2006-08-03 15:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-03  5:04 udev taking a long time during startup Piet Delaney
2006-08-03 14:09 ` Kay Sievers
2006-08-03 15:51 ` Alexander E. Patrakov [this message]
2006-08-07 23:46 ` Piet Delaney

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=44D21B7E.1060609@ums.usu.ru \
    --to=patrakov@ums.usu.ru \
    --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).