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

set/get process title #100

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

set/get process title #100

giampaolo opened this issue May 23, 2014 · 4 comments

Comments

@giampaolo
Copy link
Owner

From g.rodola on June 23, 2010 19:22:12

From: 
http://bugs.python.org/issue5672?@ok_message=issue%205672%20nosy%20edited%20ok&@template=item 

> As python gains more popularity, more and more applications run under
> CPython in a common user desktop. The problem is that if a user has 2 or
> more python apps running there is no way to identify them correctly from
> the generic "Task/Process Manager Application" (in Windows/Linux/OSX/any
> OS), because all appear as a "python" process. 

A common solution to this problem is allow a process to change its title as displayed by system tools such as ps and top. 

We might use https://code.google.com/p/py-setproctitle/ as an example and implement the same thing in psutil.

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

@giampaolo giampaolo self-assigned this May 23, 2014
@giampaolo
Copy link
Owner Author

From jlo...@gmail.com on July 08, 2010 18:29:09

From the py-setproctitle project page: 

"Notice that on Windows there is no way to change the process string: 
what the module does is to create a Named Object whose value can be 
read using a tool such as Process Explorer (contribution of a more 
useful tool to be used together with setproctitle would be well accepted)."

So it looks like we're out of luck on Windows. Thinking about this in 
retrospect, I just realized same issue occurs with java processes, 
which all show as java.exe or javaw.exe unless they are started with 
an .exe launcher process. It looks to me like there's no way to 
implement this on Windows unless we're willing to do the same thing py-setproctitle does and use a named object.

@giampaolo
Copy link
Owner Author

From jlo...@gmail.com on August 05, 2010 17:05:28

Any further thoughts on this? Should we close it out, implement it 
the same as py-setproctitle, or something else? My take on this is 
that windows is both the only place this really matters and the only place we can't properly implement it :-P 

On other platforms, tools like ps are available and can give you the 
name of the actual script pretty readily. It's really only Windows 
where this becomes a hassle because the task manager will only show 
the process executable. In light of that, personally I'd recommend closing this as WontFix. 

If we really want to solve the problem on Windows the way to do it 
would probably be to do what java launchers do, which is create an 
executable that does nothing but start up and launch your java code 
for you by finding the JRE install, firing up java.exe and calling it 
with the appropriate arguments. That way task manager shows the name 
of your launcher application instead. For example, psutil.exe is a 
launcher that starts and then runs the equivalent of exec() to fire 
up 'python.exe psutil.py' so the user can see just "psutil" in task 
manager. However, I think such a project is outside the scope of 
psutil... maybe something we could put in utils/demo, release as a separate project, or even contribute to the py-setproctitle project.

@giampaolo
Copy link
Owner Author

From g.rodola on August 05, 2010 18:18:42

This is relevant and largely used also on posix, not only on Windows, 
where a third party executable launching the actual program is the most common way to solve this problem.
This is largely discussed here: http://bugs.python.org/issue5672 I 
agree it has to be pondered over, tough, as it's far from being 
straightforward to implement in the right way as shown by 
py-setproctitle project which is a wrap around a PostgreSQL code [1] 
which implements it by using various techniques across different UNIX platforms.

However, I'm ok with closing this out as WontFix for now, also 
because I wasn't intending to put the required time/effort to look into this in the near future.

[1] http://doxygen.postgresql.org/ps__status_8c-source.html

Status: WontFix

@giampaolo
Copy link
Owner Author

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

Status: PostPoned

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