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
Implement a way to change the python process name #49922
Comments
As python gains more popularity, more and more applications run under There are more cases when this is annoying:
There are some methods [1][2] to work around it, but there are not just [1] http://davyd.livejournal.com/166352.html I hope this issue gets considered in the community to fix it, I really Regards, |
There was a similar request in Java bug database: And I'd follow the same path: provide a way to build a launcher - I suggest to close this issue, and join the discussion in bpo-4015 |
Uhm... ok, (looking at bpo-4015) I agree with that method at some Just to know, there is no prctl equivalent in Windows? Regards |
If somebody would provide a patch that adds prctl to the posix module, As for Windows: no, there is no equivalent of prctl. The task manager |
Fine, I'll try to make a patch based on the procname project in Google http://abock.org/2006/02/09/changing-process-name-in-mono/ Regards |
This patch (to python 2.7 trunk) allows to call prctl() function from Working example: marcelo@marcelo-laptop:~/src/pytrunk$ ./python
Python 2.7a0 (trunk:71261M, Apr 5 2009, 16:32:55)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
[34831 refs]
>>> os.getprocname()
'./python'
[34833 refs]
>>> os.getpid()
5601
[34833 refs]
>>> os.setprocname('hello_process_name')
[34833 refs]
>>> os.getprocname()
'hello_process_name'
[34833 refs] Before changing the process name: After changing the process name: And "killall hello_process_name" works, Gnome Process monitor shows it [1] http://fxr.watson.org/fxr/source/gen/setproctitle.c?v=FREEBSD-LIBC Regards |
As for os.getprocname() I think you can borrow some code from psutil |
Some remarks about the patch: 2 - The function should update sys.argv as well. In this case, |
Great, it's my first patch to python and I'm very happy with your Thanks Amaury, do you think is better that I should take out When I got some spare time, I'll take a look at your suggestion and the Thanks again |
Please don't provide a wrapper around ptrctrl. Instead, expose prctl as |
prctl is not portable. I always thought that the premise of stdlib is to |
Amaury Forgeot d'Arc, wrote: Sounds good, but how would you expect to set the process name |
Many parts of the stdlib are not portable. It is perfectly appropriate That's not to say that a cross-platform API cannot *also* be provided, |
I wrote a wrapper around the PostgreSQL implementation of setproctitle I've put the module on http://code.google.com/p/py-setproctitle/ : |
Great, piro! I'm taking a look at it, and it seems to use setproctitle() in BSD, and My question is because I think there's a better and supported method for PR_SET_NAME and PR_GET_NAME parameters in prctl.h: Could this module be altered to use a prctl call in Linux (>2.6.9)? Thanks a lot. |
Yes: Linux uses what in the source is referred as the
This is interesting: do you have any reference? I've tested with the difference between clobbering argv and call For what I observed, clobbering argv changes what shown in I don't know which method is better (well, I happen to prefer the
I think is probably better to have both strings updated: I'd prefer [2] http://code.google.com/p/py-setproctitle/source/browse/tools/ |
2009/12/6 Daniele Varrazzo <report@bugs.python.org>:
For example, take a look at the comments here: It seems that some utilities and programs (killall, I installed py-setproctitle, and can't kill it with killall once I set [1]+ Detenido python Another example: The gnome-system-monitor still lists the 'hello'
Sorry, but here (Ubuntu 9.10) it works the other way around: "ps"
IMHO, I'd prefer both things: to change the argv array *and* calling RegardsMarcelo F. Fernández E-Mail: marcelo.fidel.fernandez@gmail.com |
Just released setproctitle 0.2 where I also call prctl() if available.
Yup, sorry: it was the other way round :P |
2009/12/6 Daniele Varrazzo <report@bugs.python.org>:
Great! I've just tested it and it works fine here... Any possibility this Thanks! |
Only in the far future. I don't think the Python standard library should I propose to close this issue as "won't fix", with reference to the |
I agree: I started the project 4-5 days ago and, albeit very limited in |
2009/12/7 Daniele Varrazzo <report@bugs.python.org>:
>
> Daniele Varrazzo <piro@develer.com> added the comment:
>
>>> I've just tested it and it works fine here... Any possibility this
>>> module can be included in the regular python standard library, in the
>>> future?
>
>>Only in the far future. I don't think the Python standard library
>> should include a module whose version number is 0.2.
>
> I agree: I started the project 4-5 days ago and, albeit very limited in
> its scope, for portability reasons is way more complex than a simple
> syscall and needs to be tested on many other platforms.
> Of course, when I said "future" I meant "when this project is stable Thanks |
Hi, just scanned the messages. As I read it "wontfix" actually means: Ats some point in the future when the "setproctitle" project (http://code.google.com/p/py-setproctitle/source/list) has matured it will be reconsidered, correct? Yes sorry for reopening this after quite some time (~6 months), just happened to pop up in my inbox due to the latest nosy list changes... |
If it has matured, has shown to be as a "best of breed" library of it's type, and has gone through the PEP process, it could make it. That takes quite a bit of time and isn't likely to occur within the next few years (3.3 at the earliest assuming the project matures quickly). |
setproctitle is quite stable, my company uses it in production environment very heavily with python 2.x. Probably its users base is not huge, but that's because it's a relatively specialized tool. Python3 porting is not straightforward because python2 exports the original argv pointer using Py_GetArgcArgv() whereas python3 only exports a decoded version in a wchar_t* array. This may not be a showstopper: probably the original argv can still be found scanning backwards from environ: I want to test it but I haven't had requests for it yet, so it wasn't a top priority. So, while I'd be pleased to have it included in the stdlib, I'm not really convinced it would be useful to such a large audience. Anyway I'm available for any improvement it would make the tool more useful and to anybody eager to push for its inclusion. |
I think different, if python becomes even more successful to be used in desktop apps, this feature will be *very* important, because the reasons I've exposed in this thread. Regards |
No. It will also be required that it's authors agree to contribute it to |
I would have no problem with these points if the module is considered worthy for stdlib inclusion. |
Hello everybody, I've finished porting the module to Python 3, so I think it's a good starting point for considering its inclusion into the stdlib. The source is already out; tomorrow I'll test for regressions on mac osx and release the package. I'm not going to champion a PEP for its inclusion though, as I'm not the right person to do what described in the pep approval process. I have no objection if somebody wanted to push for it anyway and to fulfill the requirements outlined by Martin. Marcelo, I think it's up to you :) |
I use the setproctitle module extensively. It has worked flawlessly. What would be needed for this to get accepted? I realize one shouldn't stress such a decision, but still I feel this is something the standard library should be able to do. My justification for inclusion into the standard library is that one has to make a workaround on systems where setproctitle ISN'T installed (I don't feel such a small component should be a requirement for production use.) Everywhere I use setproctitle, I have to go:
Which is not only rather lengthy, but also IMO entirely unnecessary. As I noted, setting the process title is mostly for convenience and aesthetics, and therefore it's hard to justify the dependency. For that reason I think standard library inclusion is more relevant than otherwise. So, are there any other reasons to wait with this other than the need of a PEP and proposing that to python-dev or whatever forum is best suited? |
I'd rather not reopen this issue. It was too far-ranging, and has failed to get a specific solution. Please stop posting to this closed issue; if you want to contribute, please open a new one. I think the inclusion of the module should see a discussion on python-dev first. It then also needs to be code-reviewed, which in turn needs a committer who either volunteers to do all this work, or who is willing to take the recommendation of some other reviewer. My shallow review of the module is I would prefer to see the code structure revised. For example, c.h should go, spt_config.h should be integrated with autoconf, strlpcpy.c should go, spt_setup.c should go (IIUC) - IOW, this would need to be reformulated as a patch to the Python source tree. Of course, I can understand if Daniele would only start doing so if there was a chance that the functionality and approach is actually acceptable. |
Just for the record, I was about to try to do this, when I realized that exposing prctl requires expecting a variable number of arguments with variable types. |
It's actually simpler than you think: I don't think any of the existing Whether it's worth supporting it, I don't know. I stand by my original |
There are actually a few implementations on pypi, just search for |
Isn't this "python script doesn't show up in top correctly" issue a matter of "#!/usr/bin/env python3"? If you "#!/usr/bin/python3" (for example) instead, top seems happy. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: