Meik Hellmund wrote:
On Tue, 16 Jun 2009 12:47:29 -0400
Bob Doolittle <[email protected]> wrote:
Attached is a script I wrote to highlight inconsistencies in the
operational state of the system in cases like this. Try running it as root.
If any Linux jocks want to take a crack at porting this to Linux that'd
be great. I've been unable to find anything on Linux similar to "pargs"
on OpenSolaris that can actually show me the current environment of a
running process (ps ewww only shows the environment that was inherited
by the process, not its current environment, and I haven't managed to
get what I want out of /proc yet either). We need to see the current
environment value of $DISPLAY to deduce which display an Xnewt process
is managing.
I, too, didn't find out how to access the current environment of a Linux
process.
Both ps and /proc/pid/environ show the environment with which the process was started.
Yeah, I was particularly dismayed by the fact that the /proc/pid/environ
didn't seem to reflect current runtime state. Isn't that the point of
/proc?!?
I thought I must be doing something wrong, but I guess it's really just
a disgusting hack after all.
I imagine there's a way to extract the environment in the same way that
pargs does - pargs opens /proc/pid/as (is that equivalent to
/proc/pid/mem on Linux?) and then using the ELF headers figures out
where the environment resides in memory and preads it in but that's
beyond the scope of what I was willing to explore :). /proc/pid/a.out
helps a lot with this I expect, but I don't see an equivalent on Linux.
I discussed this with the gdm maintainer Brian Cameron a while back and
he pointed out that we could store the display and parent (gdm-binary)
pid someplace from within the utxsun wrapper that launches the X server
for future reference, and this script could use that. That would work
even if the X server failed to start up for some reason. I'm tempted to
simply extend our logging in our custom XKeepsCrashing script to cover
this case, however.
So I decided to extract the DISPLAY value from the environment of the Xnewt process.
That's fine as long as there actually is an Xnewt child of the
gdm-binary in question. This will work most of the time, I agree. For
those cases that don't work the logging extension to XKeepsCrashing may
fill the gap.
Neither bash nor pdksh have associative arrays. (There is a ksh package for
Linux which provides ksh93. But all the SRSS-on-Linux recipes recommend
installing pdksh. A relic of the times when SRSS itself had problems with ksh93.)
Yes, pdksh should no longer be required for 4.1. Sorry to have relied on
associative arrays but it really made this cross-checking algorithm
simple. Adding another array to thread the sparse display subscripts
(i.e. map them to sequential subscripts) could be done to remove the
reliance on associative arrays I think. It would uglify the code
somewhat however.
So I opted for a quick and dirty perl translation of Bob's code.
Cool, thanks! :)
-Bob
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
