All of lore.kernel.org
 help / color / mirror / Atom feed
From: Logan Rathbone <logan.rathbone@utoronto.ca>
To: linux-hotplug@vger.kernel.org
Subject: Re: Trouble with udevtrigger/udevsettle
Date: Fri, 22 Sep 2006 03:10:54 +0000	[thread overview]
Message-ID: <4513543E.7010209@utoronto.ca> (raw)
In-Reply-To: <45122DD3.2000303@phoenuxos.com>

Bryan Kadzban wrote:
> Oops, didn't send this to the list last time:
>
> Bryan Kadzban wrote:
>   
>> Logan Rathbone wrote:
>>
>>     
>>> Thus I have to wait quite a while (about a minute or so) for
>>> udevsettle to complete and have my bootup continue.  Any ideas what
>>> this could be about?
>>>       
>> Hmm...  Just guessing here, but:
>>
>>
>>     
>>> I never really have a network cable plugged into the via-rhine, but I
>>> don't see why that would make a difference.
>>>       
>> Your distro may have a rule set up to try to ifup the interface when it
>> sees an add event for it.  If this ifup is trying to use DHCP, it *may*
>> take a long time to fail when it can't find a DHCP server.  I seem to
>> remember a 30-second timeout with dhcpcd in the past, which it waits for
>> twice; that would match up with the one-minute timing you're seeing.
>>
>> I would suspect that the DHCP client should to fail immediately if it
>> doesn't detect a link, but I don't know for sure whether all of them do.
>>
>> You might try blacklisting via-rhine in modprobe.conf.  That way you
>> should never get an add event for eth0, and if the long delay is due to
>> some rule that triggers from that, it shouldn't happen.
>>     
Yes, you are right!  The udev SRPM I built from came from Mandriva, who 
set up udev rules to automatically configure and start hotplugged 
ethernet devices.  I guess they don't use udevtrigger for coldplugging, 
as that would probably produce the same problem I was having.  I suppose 
that I could reconfigure the rules to fork the dhclient process, but 
then I'd possibly risk a race condition with some later services (not 
likely, but possible).  But I guess I'm doing that anyway since my 
'network' initscript uses ifplugd to bring the interfaces up.

But I digress!  Maybe in the future I'll toy around with it and have 
udev rules handle the configuration and starting/stopping of my ethernet 
devices, but I certainly don't need that functionality atm.

Thanks for your help, guys.

--Logan

-------------------------------------------------------------------------
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-09-22  3:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-21  6:14 Trouble with udevtrigger/udevsettle Logan Rathbone
2006-09-21 11:08 ` Bryan Kadzban
2006-09-21 19:29 ` Kay Sievers
2006-09-22  3:10 ` Logan Rathbone [this message]
2006-09-22 15:21 ` Andrey Borzenkov

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=4513543E.7010209@utoronto.ca \
    --to=logan.rathbone@utoronto.ca \
    --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.