views:

2309

answers:

6

In Perl, I need to read the environment of other processes.

  • The script is running with root privileges.
  • The script will be running in both Linux and Solaris.
  • I would like a solution that's mostly platform agnostic, at least between Linux and Solaris. In Linux, examining the /env/<proc_id>/environ can get me the answer.
  • I would like to avoid having to fork. I already have a solution forking "/usr/ucb/ps -auxwwwe $pid"

Any ideas?

+3  A: 

In linux it looks like the /proc/<pid>/environ psuedofiles contain the environ variable passed when the process was created. If you have sufficient permission, you can read those.

They do not appear to track changes in the processes environment after launch.

That suggests that you would have to disect the processes memory dump to get what you're asking for.

Tricky.

dmckee
Heh. Looks like I didn't actually read he question. Sorry.
dmckee
The Solaris /proc file system (Solaris 10) does not appear to include even the original environment.
Jonathan Leffler
@Jonathan, take a look at /proc/pid/psinfo file, and see struct psinfo from <procfs.h>. Field pr_envp is the initial environment.
Martin Carpenter
+4  A: 

The first thing that comes to my mind is using GDB to attach to the process in question, and then asking GDB to get the environment for you. You can do this with the "show environment" command in the GDB shell.

It looks like there is a Perl module that can do this for you, Devel::GDB. I have not tried it yet, but it looks like a Simple Matter Of Programming to create the Devel::GDB object, connect to the process you want to inspect, send the "show environment" command, and then parse the results.

I do have to say though... when the solution is this complicated, you are probably doing something else wrong. Why do you need the environment for a random process, anyway?

jrockway
Quote:Why do you need the environment for a random process, anyway?This is part of a script that gathers information on processes running on the system. The data is saved to be analyzed later.
jac_no_k
+2  A: 

If ps can do it, like you say, then your answer can be found somewhere in the source code of ps. That would avoid the spawning of a new process.

Thomas
+1  A: 

For Solaris, you could try the procfs module from CPAN. Even though this module still seems quite young, this quote sounds hopeful:

Brian Farrell sent a very useful patch which handles inspection of argv and environment of processes other than the currently running process.

I imagine that this is probably just the initial environment (just like the environ file under linux), but that seems to be what you want?

Otherwise, although I see you say you don't want to fork, a simple solution would probably to crank ~20 lines of C to produce a small program that just spits out the environment on Solaris as the exact equivalent of the Linux environ file. I have something very similar in C already. If you're interested, I can post it.

EDIT (after reading OpenSolaris pargs.c): The environment buffer is reallocated under Solaris when the environment changes, so the psinfo pointer may be invalid. For a bullet proof solution, you need to hunt down _environ. That's all probably more hassle than you need... pargs -e <pid> might be a nicer alterative to UCB ps(1) if you do go the fork route, though.

Martin Carpenter
+1  A: 

The GNU 'binutils' package includes a CLI utility called 'strings'. See http://www.gnu.org/software/binutils/ for more info.

'strings /proc/pid/environ' - prints out a nice list of the environment variables much live 'env'.

sixerjman
A: 

The problem with /proc//environ is that it is not updated, it's just the creation stuff. If someone knows how to get the updated.... pls post.

Sem
Hello sem, welcome to Stack Overflow. You asked a question in the answer field, but this site does not work this way. To give your problem the appropriate attention, please [open a new question](http://stackoverflow.com/questions/ask). You can delete [your initial posting](http://stackoverflow.com/questions/518803#3337691) later. Take the time to familiarise yourself with [how SO works](http://stackoverflow.com/faq).
daxim