Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Determine process environment variables #52

Closed
giampaolo opened this issue May 23, 2014 · 21 comments
Closed

Determine process environment variables #52

giampaolo opened this issue May 23, 2014 · 21 comments

Comments

@giampaolo
Copy link
Owner

From billiej...@gmail.com on May 12, 2009 17:46:04

Proposal  
for addition of a new Process.environ property returning the
environment variables registered by a process, possibly as a dictionary.

Original issue: http://code.google.com/p/psutil/issues/detail?id=52

@giampaolo
Copy link
Owner Author

From jlo...@gmail.com on May 12, 2009 13:22:58

Status: Accepted
Labels: Milestone-0.1.3

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on May 12, 2009 17:22:30

On Windows this seems to be painful to determine although still possible: http://www.codeguru.com/forum/archive/index.php/t-416841.html

@giampaolo
Copy link
Owner Author

From jlo...@gmail.com on July 13, 2009 18:18:59

Ugh, this is just as ugly as determining the cmdline was, it uses basically the same
method and will likely suffer from the same reliability problems we're seeing there.

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on September 17, 2009 02:06:06

Removing 0.1.3 milestone

Labels: -Milestone-0.1.3

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on February 04, 2010 05:40:13

Labels: Milestone-0.2.0

@giampaolo
Copy link
Owner Author

From wj32...@gmail.com on February 26, 2010 02:04:27

I'm the guy who helped you with the command line retrieval on Windows. Please ignore
those CreateRemoteThread idiots. Take a look at this code (function
PhGetProcessEnvironmentVariables): 
http://processhacker.svn.sourceforge.net/viewvc/processhacker/2.x/trunk/ProcessHacker/native.c?revision=HEAD&view=markup

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on March 01, 2010 07:56:12

Labels: -Milestone-0.2.0

@giampaolo
Copy link
Owner Author

From g.rodola on July 09, 2010 13:10:26

Just for the record when we'll reconsider this, Linux code was committed as r406 and removed in r464 and r599 .

Labels: -Progress-0in4 Progress-1in4

@giampaolo
Copy link
Owner Author

From g.rodola on September 24, 2010 16:40:43

Status: PostPoned

@giampaolo
Copy link
Owner Author

From g.rodola on March 01, 2011 09:51:11

On FreeBSD we can use kvm_getenvv(): http://fuse4bsd.creo.hu/localcgi/man-cgi.cgi?kvm_getenvv+3

@giampaolo
Copy link
Owner Author

From g.rodola on January 24, 2012 13:23:25

Issue 247 has been merged into this issue.

@giampaolo
Copy link
Owner Author

From g.rodola on January 31, 2012 08:42:15

Another article about Windows: 
http://www.codeproject.com/Articles/25647/Read-Environment-Strings-of-Remote-Process

@giampaolo
Copy link
Owner Author

From g.rodola on February 01, 2012 10:22:40

Reopening as I have a partial working patch for Windows.
I'd like to have this ready for 0.5.0.

Status: ReOpened
Labels: Milestone-0.5.0

@giampaolo
Copy link
Owner Author

From g.rodola on February 01, 2012 11:06:08

Linux implementation readded as r1259 .
Windows implementation added as r1260 .

Labels: -Progress-1in4 Progress-2in4

@giampaolo
Copy link
Owner Author

From g.rodola on February 01, 2012 14:53:24

kvm_getenvv() on FreeBSD can only be used if /proc filesystem is mounted (and it's not by default).
Partial implementation is below but I guess we better off not supporting FreeBSD at all.

static PyObject*
get_process_environ(PyObject* self, PyObject* args)
{
    long pid;
    char **env;
    struct kinfo_proc *pinfo;
    int num;
    static kvm_t **kd;

    if (! PyArg_ParseTuple(args, "l", &pid)) {
        return NULL;
    }

    kd = kvm_open(NULL, NULL, NULL, O_RDONLY, NULL);

    pinfo = kvm_getprocs(kd, KERN_PROC_PID, pid, &num);
    if (pinfo == NULL) {
        return PyErr_SetFromErrno(PyExc_OSError);
    }

    env = kvm_getenvv(kd, pinfo, 9086);
    if (env == NULL) {
        return PyErr_SetFromErrno(PyExc_OSError);
    }

    return Py_BuildValue("i", 33);
}

@giampaolo
Copy link
Owner Author

From david.da...@gmail.com on April 24, 2012 21:45:37

I fixed the heap corruption issue happening with the get_process_environ() call on windows in r1297

Cc: g.rodola

@giampaolo
Copy link
Owner Author

From g.rodola on April 25, 2012 04:57:59

Great! Thanks.

@giampaolo
Copy link
Owner Author

From g.rodola on April 25, 2012 05:57:13

Looking back at this I start to doubt the usefulness for two reasons:

- on Linux this seems to work just fine but if the environment of the process is modified the change is not propagated:

>>> p = psutil.Process(os.getpid())
>>> os.putenv('XXX', '1')
>>>'XXX' in p.get_environ()
False
>>>

- on Windows this can be used for the current process only; for all other 
processes, including the ones owned by the current user, we get an AccessDenied 
exception - also, if the environment of the current process is changed we also get AccessDenied.


That said, it probably make sense to give up on this.
I'm going to leave this open for a while a take a definitive decision later.

Status: WaitingForReview

@giampaolo
Copy link
Owner Author

From g.rodola on June 26, 2012 10:08:43

More info about Linux not updating /proc/PID/environ: 
http://serverfault.com/questions/66363/environment-variables-of-a-running-process-on-unix/79463#79463

@giampaolo
Copy link
Owner Author

From g.rodola on June 26, 2012 10:31:22

Ok, I'm still inclined to remove this due to the unreliabilities explained 
above for  both Windows and Linux. Removal done in r1366 and closing this out as WontFix.

Status: WontFix
Labels: -Milestone-0.5.0

@giampaolo
Copy link
Owner Author

From g.rodola on March 02, 2013 03:49:26

Updated csets after the SVN -> Mercurial migration: r406 == revision 
3e6905e0c623 r1260 == revision a299e2431879 r1297 == revision e278f365986c r1366 == revision b1dd9bd9ba25

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant