--=-i6oE1seSxj/G7PvELDUf
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Fri, 2002-04-26 at 09:04, Michal Jaegermann wrote:
> So? First of all you are actually not interested in a process id of
> that grep (or awk, or whatever). How you can assure that something
> started later will have a higher pid? The answer is "no way".
>=20
Okay, maybe the word "guaranteed" was a little strong.=20
The linux kernel uses an incremental approach to generating process
ID's, or PID's as we know and love them. Some people have written
various kernel patches that generate random PID's in order to minimize
PID prediction attacks, but we won't go into that. Let's just assume
that the kernel still handles PID's incrementally. In order for a
duplicate or earlier PID to generated/assigned the kernel would have to
[quickly] cycle through all avaiable PID's in order to loop back around.
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? Sure, spawn N number of processes
immediately after the X server starts and before the renice where N is
the number of available PID's. If someone wants to go through that
troubel to keep me from re-nicing my X server, god bless them.
Crap shoot? Hardly.
Your point about multiple X-servers is a good one, however as I
mentioned this is just a plain old desktop. While it is something that I
would absolutely consider if I was releasing an end-all solution for the
community, it's just not an issue for the problem I'm trying to solve.=20
However, I'm still trying to find a good place to automatically run this
command in the gdm sequence... ;-)
--Chris
> > So that will work every time...guaranteed.
>=20
> No, you are playing a crapshot. It has pretty good chances to work if
> you have done that rather soon after you started your machine (and if do
> not have a big crowd of users then this helps as well). But in general,
> especially if you are restarting a server later, all bets are off. A
> saving grace in this particular case is that a failure does not have
> dire consequences.
>=20
> In an absence of 'pidof' an old trick to do things of that sort
> looks like that
>=20
> ps ax | awk '/[X] /{print $1}'
>=20
> Think for a moment why it works. :-) There are some variations,
> of course, and you have have to be careful not match too much.
>=20
> ps ax | awk '/\/[X] /{print $1}'
>=20
> could be better. As an exercise redo that filtering only with 'sed'
> (and then you can pick your regex delimiter :-).
>=20
> On the top of it you may have really more than one X server going
> with different displays (I often do on some machines). In such
> situations you have to loop through all pid's or you will be just
> chaning priorities on some random one and who knows which is that.
>=20
> > However, the pidof is a much better solution. Completely unaware it
> > existed. Thanks.
>=20
> It is in 'root' path so it is normally "invisible" from non-root
> accounts.
>=20
> Michal
>=20
>=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/)
--=-i6oE1seSxj/G7PvELDUf
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
iD8DBQA8yYl6R6ATq7AtBW4RAnCIAKCWPrjMqH0kJP2Rztuac1uGuHkCsgCfZHet
HWRk1UQlk50oZJqD6oVk0WA=
=9Oq0
-----END PGP SIGNATURE-----
--=-i6oE1seSxj/G7PvELDUf--
