Support for set process name (prctl()) on UNIX

[giampaolo]

From billiej...@gmail.com on May 09, 2009 14:38:04

On Python bug tracker there's a discussion [1] about adding a new function
to the os module to change the name of the executable as it is shown by ps
and top.

This could be useful since on a UNIX system there might be many processes
running under the name "python".
In such cases it's desirable that the process is displayed as "foo" rather
than "python foo", and this seems to be possible with prctl(), at least on
Linux.

I still don't know the implementation details implied (for example: is
prctl() available on other UNIXes?) but it would be a useful thing to have.


[1] http://bugs.python.org/issue5672 [2] http://linux.die.net/man/2/prctl

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

[giampaolo]

From billiej...@gmail.com on May 09, 2009 05:48:18

It seems that on FreeBSD we might use setproctitle(): http://www.rocketaware.com/man/man3/setproctitle.3.htm

[giampaolo]

From billiej...@gmail.com on May 11, 2009 09:20:38

After some research it turned out this is not easy to implement as I thought at first
because of some major problems related to the portability.

First of all, setproctitle() seems to be broken on OS X: 
http://lists.apple.com/archives/darwin-userlevel/2001/Dec/msg00004.html Despite the issue goes back to year 2001 I asked Jay to verify whether setproctitle()
is available on a modern OS X system but unfortunately he discovered it is not.
At a first look it seems there's no setproctitle() substitute. That doesn't mean it
wouldn't be possible to implement such thing in other ways at all but it would surely
be a lot harder.
In summary the OS X support would be let off.

Another big problem is that neither prctl() nor setproctitle() is able to change
other process names except the current one.

Windows support is definitively left out since there's no such prctl()/setproctitle()
equivalent at all.

This would let us with a support working only on 2 platforms out of 4 (Linux and
FreeBSD) and only for the current process, which goes against the multiple-processes
imprint the library has lead so far.

For all these reasons I think it's better to close this one as WontFix, unless we
don't find different solutions in future.

Status: WontFix