Re: [PATCH] Only lookup uid/gid when applying rules

[Kay Sievers <kay.sievers@vrfy.org>]

On Sat, 2006-08-05 at 03:20 +0100, Roy Marples wrote:
> On Saturday 05 August 2006 03:05, Kay Sievers wrote:
> > On Sat, 2006-08-05 at 02:49 +0100, Roy Marples wrote:
> > > On Saturday 05 August 2006 02:35, you wrote:
> > > > Resolving in the event process will work around the current problem,
> > > > that we fail, even if we don't have a matching device, that's true, but
> > > > the real problem that we block still persists. Sure, it will solve
> > > > Gentoo's "tss" problem, but that's not enough reason to add resolving
> > > > of id's to every event process.
> > >
> > > So tell me how to fix this in udev.
> >
> > We may be able to handle a lookup timeout. You could set a reasonable
> > bind_timelimit in ldap.conf, so it will not block for more than a few
> > seconds.
> 
> Ok lets say that udev ships with a new rule that has a new user/group lookup 
> called "foo".

Udev usually ships no rules with id's, which are not part of the base
system.

> You have instantly broken existing LDAP installs that do not have foo 
> in /etc/passwd or /etc/group

Right, then you system is broken and it will result in a bootup delay,
which is acceptable.

> Now should the onus be on distro's to magically add foo even though it *may* 
> be not needed, or should it be on udev to work out if it even needs to lookup 
> the user/group "foo"?

You should fix your base-system, which is causing the trouble, simple as
that. 

And what's the problem? With that one unresolvable group name, it will
take 60 seconds to timeout on bootup waiting for ldap. Then continue,
and you can fix that problem on your system:
  time /sbin/udevd --daemon
  real    1m0.013s

If you really care about such a case, put:
  bind_timelimit 3
in your:
  /etc/ldap.conf
and it will take 6 seconds:
  time /sbin/udevd --daemon
  real    0m6.012s

You are trying to trade an valuable optimization of udev for a rare-case
configuration error that happened in your distro, cause of bad
packaging. That's really not an interesting deal.

Again, we could try to work around such an error, that would be nice to
have, but not until we are sure what's the right fix for it, and pushing
the resolving into the event processes isn't it.

Kay


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