how do you find the environment for a running p...

So how do you find the environment for a running process? It depends on the OS.

* Solaris
/usr/ucb/ps eww <pid>
or in Solaris 9 and up
pargs -e <pid>
Here, e for environment and ww for extra wide (see `man -s 1b ps'). Note that 
with the first command, any user can look at any process before Solaris 9. 
Beginning with Solaris 9, or more precisely, Solaris with the relevant security 
patch, you can only look at the environment of your own process or if you're 
root. Solaris 10 pargs has the same restriction, or security enhancement as Sun 
would call it.
See http://sunsolve.sun.com/search/document.do?assetkey=1-26-102215-1
One more way, quite involved though, is by using mdb.
See http://blog.curthread.org/posts/solaris/mdb/display_envp.html
Also see the paragraph labeled IMPORTANT below.

* Linux
ps eww <pid>
cat /proc/<pid>/environ
Must run as process owner or root. The second command returns all strings 
jumbled together, which can be piped to a filter to separate:
cat /proc/<pid>/environ | perl -pne '$a=chr(0);s/$a/\n/g'
Also see the paragraph labeled IMPORTANT below.

* Windows
In Process Explorer (available from sysinternals.com), double click the 
process, go to Environment tab. If the string is too long, you can highlight 
and copy and paste into Notepad.

* Other OSes
All BSD's and BSD "derivatives" accept `ps eww <pid>' command. Failing that, 
see if you have gdb installed. If so, `gdb path_to_process_executable <pid>' 
and enter: 
set variable $p = (char **)environ 
while *$p 
print *$p++ 
end 
(Note that gdb `show environment' does NOT show the attached process 
environment.) Without gdb, create a process core image, run strings on the core 
file, and find the environment variables usually toward the end of the output 
(possibly not very readable). gcore is available on most UNIXes. If not, send 
to the process a signal whose disposition is dumping core.

                      ********** IMPORTANT **********
On UNIX and Linux, what I call running process environment is not technically 
accurate. It's really the environment at the time the process was created 
(fork() and exec()). If the process later changes its environment variables 
(create, unset, change value), the above method won't detect the change. (On 
Solaris, even the mdb method won't help.) Windows does not suffer from this 
problem.
                      ********** IMPORTANT **********

If you see incorrect environment setting, correct it by referring to the 
documentation of the application software. If the documentation has no such 
information, the general solution is to start the process from a shell or batch 
file where the correct environment is pre-set. Suppose a UNIX or Linux process 
XYZ has $PATH set to mistakenly include /usr/ccs. Simply type
export PATH=<desired path without /usr/ccs>
XYZ
to launch the application
Sometimes the problem is that you can't start XYZ and the solution is the same.

That sounds trivial to a UNIX/Linux user, but may not be so to a Windows user. 
Most Windows programs are started from Start | Programs | ... How do you 
control the environment? It's the same answer. When you navigate to the program 
from Start | Programs | ..., right click to go to Properties | Shortcut (second 
tab), use the long strings in Target and also "Start in" (if not empty) to 
manually start the program. Go to DOS (Start | Run | cmd | OK). Type
cd /d <"Start in" from above>
set <envvar>=<desired value>
<"Target" string>
Here <envvar> is the environment variable you wish to change. Make sure there's 
no space around "=". Many times I have to manually change %PATH% to make it 
much cleaner as in this example:
set path=c:\windows\system32;c:\Program Files\Oracle\jre\1.3.1\bin
Sometimes I explicitly set %TNS_ADMIN% to some path I want to troubleshoot 
Oracle TNS connection problem. One practical example of solving a problem this 
way is in section "Can't launch Net Manager and Config Assistant" of
http://yong321.freeshell.org/oranotes/LdapInsteadOfTnsnames.txt

   For Windows NT Users: To find the "Start in" and Target for a shortcut in 
   Start | Programs | ..., navigate to C: | Winnt (%SYSTEMROOT%) | Profiles | 
   <user you, or All Users> | Start Menu | Programs | ... | Properties.

Obviously, you can put the three DOS commands I listed above in a batch file 
(XYZ.bat, e.g.) in order to save typing next time. You can also change the 
environment setting in Control Panel | System. But the approach outlined here 
avoids globally changing the environment which other programs unfamiliar to you 
may rely on.

Note that although a messed-up path is a common cause of application problems, 
it's not the only one. Even for paths, the environment variable to correct may 
not be $PATH on UNIX/Linux; it may be $LD_LIBRARY_PATH or $SHLIB_PATH, 
$CLASSPATH, or even without the word "PATH" such as $LD_PRELOAD. On Windows, 
however, DLLs are searched in the order of %PATH%, just like EXE files; Windows 
has no $LD_LIBRARY_PATH equivalent.

Windows has one more complication and this probably explains some of the 
mysteries that sometimes only a reboot can solve a problem. The above method 
only works for interactive processes. Windows services are a very different 
type of processes. Even if you change the starting shell environment, or the 
setting from Control Panel | System | Advanced | Environment Variables, a 
stopped and restarted service still uses the old environment. Let's say you 
notice that Microsoft SQL Server jobs are failing and Process Explorer shows 
that the SQLAgent.exe process seems to have incorrect %PATH%. You also find 
that you can execute a DTS task interactively (not by scheduling a job) if you 
take the above approach (run mmc.exe /c ... in a clean %PATH% DOS shell) but 
fail without cleaning up the shell.  The problem with the restarted service 
even after Environment Variables are changed in Control Panel is that a service 
is always a child of SERVICES.EXE, which is a child of WINLOGON.EXE, which is a 
child of SMSS.EXE, which is a child of System. (NT doesn't have SMSS.EXE) None 
of these processes can be killed without crashing the server. SERVICES.EXE uses 
all environment variables set in Control Panel. Since these processes exist and 
never exit since server bootup, they still take the old environment setting 
after you change it in Control Panel. The only way to change their running 
process environment (for individual services to inherit) is by reboot after you 
properly set it in Control Panel.