Determinig the environment of a process

[Ralph Grothe]

Hi,

on Linux I can do something like


JOB=sleeper sleep 10 & tr \\0 \\012 [1] 5449
JOB=sleeper

to access a process' environment,
thanks to the procfs.

I miss this in HP-UX.
Or is there another way to introspect a process'es environment by HP-UX vanilla tools
(i.e. no tusc or other third-party tool)?

p.s.
Btw, what's the Saxon Genitive for words ending on "s" like process?
Is it process'
or process's
or process'es
?

[RAC_1 · Accepted solution]

Are you looking at getting the environment details of a running process??
If yes, there was a utility (some postsde on forums) procstat. That may help you.

As you must be aware, for determining the environment for a process, that will be run, you can do env, set before actually starting it.

And it is processes - I think.

Anil

[Mark Greene_1]

"Btw, what's the Saxon Genitive for words ending on "s" like process?"

An interesting way to phrase the question!

Either process' or process's would be appropriate. The former used to be exclusivily prefered 20-25 years ago, but the latter is now acceptible.

[Rodney Hills]

"lsof" can tell you the open files as well as the current working directory.

Again it is a third party. (but in the *nix world building and sharing tools is a way of life...)

I vote for- processes

HTH

-- Rod Hills

[Patrick Wallek]

Hmmm....Saxon Genitive is a new term for me. For those not familiar with its meaning, it is the possessive form of a word.

In this case, the possessive of process is, I think, process'.

The plural form of process is processes.

[Patrick Wallek]

Hmmm....It appears that to be grammatically correct the possessive of process is process's.

For more information on all of this, try this link:
http://www.grammarmudge.cityslide.com/articles/article/426348/4944.htm

**Nothing like an English grammar lesson in the middle of a technical forum**

[Ralph Grothe]

Anil,

thanks for pointing me to procstat.
I found a project page at http://freshmeat.net/projects/procstat/
I will install this tool first on a test box to see if it satisfies my needs.

A pitty that HP-UX hasn't an interface similar to /proc on Linux and Solaris.
Wish Dietmar Konermann c/o HP would read this thread.
Then he could also take this topic on the wish list for future HP-UX releases.
He was so graceful to take up my uttered disappointment in another thread about the lack of a loopback filesystem (that lets one mount filesystem/image files) in HP-UX, and officially tag it as request for realization.

Mark,

the first version (viz. process') is I think what I learned in primary school.
This also accords to your epochal classification because that was some 30 years ago.

Rodney,

we have lsof already installed on quite a few boxes (an indispensible tool).
But I haven't found from lsof's manpage any reference or switch to getting a process' environment displayed.
The only references to environment relate to LSOFDEVICECACHE which is an environment variable that could point to an alternative place of a caching file.

Patrick,

I would bet that the term Saxon Genitive isn't familiar to most native English speakers.
Probably it's only an artificial nomenclature that they taught kids in German schools ;-)

[RAC_1]

Ralph,

There is a utility as gcore. This creates
the core image of the running process. May be this will help you. You will have to install two patches to get this.

gcore -p "pid" -o "object_specifier"

PHKL_31876
PHCO_32173

Anil

[Ralph Grothe]

Anil,

since I had to defer the building of procstat until now I have only yet realized that this is reading its information from a Linux procfs and thus will only run on a Linux kernel :-(


# cat README
Apr 26, 2000

Released under the GPL.

procstat reads statistics from /proc//* for a process. It will tell you;
what files it has open, what sockets it has open, what address space it is
using, it's cwd, it's root dir, shell environment variables, or give quick,
short statistics about it.

This has only been tested in linux kernel 2.2.x and may or may not work in
earlier or development versions of the kernel. It will only work with linux.

This is the initial release.

[Dietmar Konermann]

Ralph,

the functionality you are searching for is not available in vanilla HP-UX. However, since this is an user land issue, You could attach to the running process using a debugger and then have a look at its "environ" array of strings.

BTW, for submitting official enhancement requests you should contact your local HP Response Center. All I did in the previous thread was posting an ID for an *existing* request.

Best regards...
Dietmar.

[Ralph Grothe]

Hi Dietmar,

your hint towards attaching to a running proc with a debugger sounds very promissing to me.
However not being a C hacker I lack mastery of the adb (I take I can use it for this purpose), and hence a liitle more help.
From adb's manpage I see that I could use -P switch to attach to a PID.
If I recall my embryonic C knowledge the main function gets as first two args the arc (argument count) and an **argv (argument array), and optionally an **env (environment array).
The latter I think can be fetched by the syscall getenv().
So it would be great if there was some sort of debugger getenv() call.
On the other hand I thought in order to fetch symbols from an object file (or proc/executable) that binary must have been compiled with an option that reserves memomry for the symbols as well, and that this would almost never be done on a final program release past the debugging stage because of waste of memory, right?
So will there be a chance at all to fetch environment variables from a non-debug-built binary?
But even if the binary provided symbol tables how would I have to invoke, say the adb debugger, to get the contents of environment variables displayed (i.e. which adb commands, typing, formatting etc.)?

[Ralph Grothe]

Em, forgot,
what the hack is my local HP Response Centre?
I can't believe it's the Berlin HP subsidiary.
Thought all vital design and coding decissions were made in Hanover Street anyway?

[Steven E. Protter]

Maybe its not local, but if you have a software contract you can call A HP Response center or do an online case on this issue.

I don't know how that would be done in Berlin.

I am very interested in this issue because being able to determine the environment of a process after or while its running.

SEP

[Ralph Grothe]

Hi Steven,

we do have support contracts to issue HP support cases over a countrywide hotline.
Probably I should ask them, or browse a bit through ITRC.

To pick up the thread,
Dietmar has mailed me a hack meanwile that seems to apply to gdb.
Unfortunately I have installed gdb on only one (other) HP-UX box.
But I will try there.
This hack looks to me a bit of a mixture between shell scripting and C (viz. thingies that look like C type casts to me).
It seems to be a sort of gsb scripting dialect.
I'm sure it would make more sense to you,
although it's easy to gather.
Maybe Dietmar was so kind to also post this hack here for the community.
(then I could also thank him with some points ;-)

[Dietmar Konermann]

Ralph,

your "local HP Response Center" is the German one, located in Ratingen.

For enhancements you should go the official way (which is logging a call with the repsonse center for that) since the request should also contain information about business impact/opportunities and your support level to get the desired drive. ;-)

For the technical background... an exec'ed process gets its enviroment as "an null-terminated array of character pointers to null-terminated strings" (man exec(2)).

For 32bit processes this gdb script usually works (no guarantee!):

# env32.gdb
set $start=*0x40001000
set $i=$start+4
printf "\nCommand Line:\n"
while *$i != $start
set $i=$i+4
end
while *$i != 0
x/s *$i
set $i=$i+4
end
set $i=$i+4
printf "\nEnvironment:\n"
while *$i != 0
x/s *$i
set $i=$i+4
end
q


For 64bit processes try this script instead:

# env64.gdb
printf "\nCommand Line:\n"
set $i=0
while ((char **)__argv)[$i] != 0
print ((char **)__argv)[$i]
set $i=$i+1
end
printf "\nEnvironment:\n"
set $i=0
while ((char **)__envp)[$i] != 0
print ((char **)__envp)[$i]
set $i=$i+1
end
q

To call gdb with a script file, e.g. env32.gdb:

# gdb -x env32.gdb

No guarantee for all that stuff.

Best regards...
Dietmar.