Peter Ross wrote:
Afterwards there was the idea of concurrency - and it
problems than it's worth it, especially if you have to cover the
"unusual" setups as well (boots over net, network directory
services, slow dynamic DHCP, to name a few)
Ubuntu 10.04 actually has a cyclic dependency if you NFS boot.
My best slowdown under Linux (back under CentOS 5.x)
was using LDAP
in /etc/nsswitch with files as fallback.
Bind softly instead of hard. Caveats are same as NFS soft vs. hard
binding. And yeah, files should probably be first.
Configured it, worked with it, all good - until next
ping.. no answer, one, two, three minutes. Walking over, seeing udev
timing out.. for every device it configures it waits for LDAP ..
which cannot be reached because there is no network yet.
I ran into such a thing on a CentOS4 box once. What happened was this:
1. stupid local sysadmin creates a file /etc/sysconfig/networking/foo
with an LDAP group.
2. stupid RH init script does something like
ifcfg_scripts=$(ls /etc/sysconfig/networking | grep ifcfg)
3. ls dutifully tries to resolve foo's group.
group doesn't resolve via files, so it asks LDAP
Network isn't up yet (duh), so that hangs.
Hangs for TWENTY MINUTES, because its hard-bound, and each
(sequential) LDAP takes 10s or something to time out, and for some
reason there's a whole lot of LDAP queries even though there's
just that one file.
4. I go crazy for half a day, isolating which init script it hangs
at, then which line, then finally going "wtf? how can ls hang for
twenty minutes?!" before finally working it out.
chgrp root foo, problem immediately goes away. Sigh.
greybot> ls is a tool for interactively looking at file
greybot> information. Its output is formatted for humans and will
greybot> cause bugs in scripts. Use globs or find instead. Understand
greybot> why: http://mywiki.wooledge.org/ParsingLs
Amusing was the pingpong of the bug reports I found -
init, udev and
nsswitch - everybody reckons it was the other project's fault;-)
Red Hat closed it and declared it a non-issue.