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

Process.name() cache may be outdated #692

Closed
PierreF opened this Issue Sep 29, 2015 · 2 comments

Comments

Projects
None yet
3 participants
@PierreF
Contributor

PierreF commented Sep 29, 2015

psutil cache the process name based on (pid, creation_time), but in case of exec it could change.

I can reproduce this issue with:

  • start bash in one terminal. Use "echo $$" to find PID of this shell (e.g. 1626)
  • Run a psutil.process_iter() loop => process.name() return "bash" when I'm on pid == 1626
  • run "exec sh" on the bash terminal
  • Re-run the same psutil.process_iter() loop, process.name() is still "bash"

The loop used is :

for p in psutil.process_iter():
    if p.pid == 1626:
        print(p.name(), p.cmdline())

Note: the cmdline() - which is not cached - show the new name.

A way to request name without using cache may be valuable.

@adrianreber

This comment has been minimized.

Show comment
Hide comment
@adrianreber

adrianreber Oct 16, 2015

I have the same problem with checkpointing and restarting processes. During restart the process name is the name of the checkpoint/restart tool (CRIU) and once the process has been restored it changes to the program being restarted. So sometimes I get 'criu' as process name and sometimes the actual process name after the restore. It depends on the point in time at which the loop over psutil.process_iter() is run.

adrianreber commented Oct 16, 2015

I have the same problem with checkpointing and restarting processes. During restart the process name is the name of the checkpoint/restart tool (CRIU) and once the process has been restored it changes to the program being restarted. So sometimes I get 'criu' as process name and sometimes the actual process name after the restore. It depends on the point in time at which the loop over psutil.process_iter() is run.

adrianreber added a commit to adrianreber/p.haul that referenced this issue Oct 16, 2015

p.haul: work around process name caching in psutil
The python module psutil caches the process name so that sometimes
restored process have 'criu' as the process name. psutil uses the
process' PID and start time to decide if the process name has to be
updated. But as the start time does not change it will sometimes not
change to the restored process name but it will keep listing the restore
process as 'criu'. This is tracked at:

 giampaolo/psutil#692

Signed-off-by: Adrian Reber <areber@redhat.com>

adrianreber added a commit to adrianreber/p.haul that referenced this issue Oct 16, 2015

p.haul: work around process name caching in psutil
The python module psutil caches the process name so that sometimes
restored process have 'criu' as the process name. psutil uses the
process' PID and start time to decide if the process name has to be
updated. But as the start time does not change it will sometimes not
change to the restored process name but it will keep listing the restore
process as 'criu'. This is tracked at:

 giampaolo/psutil#692

Signed-off-by: Adrian Reber <areber@redhat.com>

adrianreber added a commit to adrianreber/p.haul that referenced this issue Oct 16, 2015

p.haul: work around process name caching in psutil
The python module psutil caches the process name so that sometimes
restored process have 'criu' as the process name. psutil uses the
process' PID and start time to decide if the process name has to be
updated. But as the start time does not change it will sometimes not
change to the restored process name but it will keep listing the restore
process as 'criu'. This is tracked at:

 giampaolo/psutil#692

Signed-off-by: Adrian Reber <areber@redhat.com>

@giampaolo giampaolo closed this in 999dc85 Oct 16, 2015

@giampaolo

This comment has been minimized.

Show comment
Hide comment
@giampaolo

giampaolo Oct 16, 2015

Owner

This is now fixed in latest GIT version.

Owner

giampaolo commented Oct 16, 2015

This is now fixed in latest GIT version.

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