--=-nNayDqcIIaDxKUbunmpe Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2002-04-26 at 11:39, Michal Jaegermann wrote: > Why "quickly"? I have seen many times PID counter to wrap around > without really trying. There are only 15 bits for that number. >=20 Quickly, because the amount of time between the X starts and the renice is incredibly minimal. huh? pid_t is an integer, which is a 32 bit number (well, 31 I think since it must be sign safe). Again, you must be using some strange version of linux, I've never seen a boot sequence generate so many processes that any counter actually wraps around. I've seen this happen with long uptimes of course, but never at boot. I didn't actually dig into the source, so are they reserving 16 bits for something else and only using a portion of pid_t? I don't suppose you could post/email a copy of the boot sequence that generates that many processes? I find it hard to beleive it exists and is certainly not common. In fact, I've run my code a few times and by the time the user can log in, the PID's are slightly over 2000. And as we've stated, the renice is already done by this point. So I fail to see how you will *ever* wrap the PID. It just won't happen unless you try to intentionally spawn processes in the hopes of breaking it. =20 So unless you can post an example of a box where the counter was wrapped around by the time the user can log in (and why it would ever happen on my linux box), I'm going to consider the case closed and problem solved. I do thank you for pointing out the pidof command, very useful. > > Seeing as how we are talking about re-assigning the PID nicety shortly > > after the X server is started, the possiblity of the kernel looping > > through all avaiable PID's to actually choose a lower PID is pretty > > high. Could you break this? >=20 > Yes, no problem. Without any sweat. >=20 > > Crap shoot? Hardly. >=20 > Well, as far as a good sysadmin practice is concerned there is > really no more polite way to call that. >=20 > You just refuted your own claims. There is no point to use broken > hacks; especially when a correct way to do that is simpler even if > 'pidof' is not available. =20 >=20 > > Your point about multiple X-servers is a good one, however as I > > mentioned this is just a plain old desktop. >=20 > On a "plain old desktop" in my home my wife and my son are using the > same machine (I usually hack on something else :-). They like their > desktops in a totally different way in many details. So the second > person which showed up after X was restarted for whatever reasons > fires up, from a text console, the second server on a display ":1" > and now you can trivially switch between these desktops usually by > going from a console 7 to 8 and back. This still does not include > those clients which may come over a network with a display somewhere > else - which happens quite regularly. This IS a multiuser operating > system. >=20 > Michal >=20 Again, you're desiging a generic solution for a problem that doesn't exist, at least in my world. The computer in question is not a multi-user server, there is only one (and ever one) X process. The pidof command will work perfectly every time. >=20 >=20 > _______________________________________________ > xfree86-list mailing list > xfree86-list@redhat.com > https://listman.redhat.com/mailman/listinfo/xfree86-list > IRC: #xfree86 on irc.redhat.com --=20 Homepage: http://interclypse.net Registered Linux user #215241 (http://counter.li.org/) --=-nNayDqcIIaDxKUbunmpe Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8yaYtR6ATq7AtBW4RAgGqAKCal2UvzBiVuhCWVPXCKDhwDI42bACdEOJg BYMhvmTANrNRrzKC81ZWvhQ= =Q87O -----END PGP SIGNATURE----- --=-nNayDqcIIaDxKUbunmpe--
