[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#459403: libuuid1: missing depends on non-essential package passwd

On Mon, Jan 07, 2008 at 11:34:07AM +0100, Bastian Blank wrote:
> On Mon, Jan 07, 2008 at 03:23:23AM -0500, Theodore Tso wrote:
> >                            So, I am doing so now.  Any objections if I
> > add a dependency on passwd for libuuid1?  The aternative would be to
> > roll-my-own useradd/adduser functionality, but that would be a real
> > PITA....
> There are several other possibilities:
> - Move the user creation. It is necessary for uuid-runtime (uuidd), not
>   libuuid.

It's actually needed in libuuid, because one of the modes how it can be
used is a program can be setgid libuuid.  If so, then when it calls
libuuid, it can optionally save the clock sequence number in
/var/lib/libuuid, and to detect circumstances when the clock goes
backwards.  This guarantees that uniqueness, and makes the UUID
generation compliant with RFC 4122.  Without libuuid being setgid, or
without the uuidd package installed, the time-based UUID will
*probably* be unique, but if the time gets reset, and you get
very. Very unlucky, or if you have multiple SMP threads generating
huge numbers of time-based UUID's, you could generate duplicate

> What is the reason for this deamon anyway? It linearises the requests
> and limits the amount of available uuids.

So there are some programs that like to use time-based UUID's because
they tend to sort much better (particularly if you byte-reverse the
UUID) when they are used as keys in a database.  One such program
generates a *huge* number of them while initializing its application
database.  It does so in multiple threads and multiple processes
running in parallel, and it was running into problems because it could
end up generating duplicate UUID's.

The uuidd linearises the requests, yes, but in a very clever way where
each particular thread can request a block of UUID's (with contiguous
times) so it actually allows a much, MUCH larger number of UUID's to
be generated, with *significantly* less CPU overhead.  I know of only
one application program that generates this many UUID's (as in tens of
thousands per second).  Unless you use this application, it's
relatively unlikely that you need it; however, it is a matter of
correctness as well --- if you want to guarantee uniqueness on an SMP
system, and guarantee uniqueness in the face of an unreliable clock
that might go backwards, implementing the requirements of RFC 4122,
it's necessary.  By default though most applications use random
UUID's, for which none of this rigamarole is necessary.

So without uuidd installed, the amount of time to generate 100,000
UUID's is 3.2 seconds.  With uuidd installed, the amount of time to
generate 100,000 UUID's drops down to 0.091 seconds.

	    	       	       		     - Ted

Reply to: