Add an utility function like psutil.process_iter()

[miniwark]

If i am not mistaken, actually the only way to make iteration with the processes is by using process.Pids(). In the psutils documentation it is not recommended for iterations because of possible PIDs number reuses.

For now, using process.Pids() is somewhat Ok, but implementing a PID cache like in psutil.process_iter() would be a good improvement :)

[shirou]

I have not measured performance, but gopsutil's Pids() returns only []int32 and, other information inside Process is read only when that function (such as p.Status()) is invoked. So, I believe there are no need to cache or something else, currently.

Off course, PR is always welcome!

[alficles]

This isn't a performance issue, it's a correctness issue.

As it stands, it is impossible to get information about a consistent list of currently running processes. The only mechanism for getting running processes is process.Pids(). But the process ids returned by that list can not only terminate (and thus be invalid), but be reused. This means that if you ask for a list of running processes, then iterate over those processes, you can receive information about processes that do not match the list you originally got.

[alficles]

To add to my prior comment... using pids as the primary identifier is deeply troubling. Consider:

func KillChildren(p *process.Process) {
  children, _ := p.Children()
  for _, child := range children {
    child.Kill()
  }
}

This appears to be obviously correct, but the library uses pids under the hood. The pids can be reused between the time that p.Children() returns them and the time child.Kill() is called. This can result in arbitrary system processes being killed.

[neoliv]

@alficles
I asked myself the same question but I don't see how to do otherwise. As far as I know the PID is the main/primary key to access process information.

• Do you know of a lib that is handling this issue?
• Did you encouter cases where this issue occured in real life?
  One way to make your code more robust would be to check the child PPID before killing it.

[miniwark]

@neoliv

• As stated in my first post psutils have implemented a specific PID cache in psutil.process_iter() to solve this issue. So psutils is the [python] lib who is already handling the issue. As gopsutils try to port psutils functionalities this why i have open the ticket.
• I am not actively maintaining tyu for now, but i am thinking to add later a top or glances like feature (mainly because i want to remove the lines in the README who say it's not like top). Witch mean than i will need to track each processes... If PIDs changes too much, then the displayed infos will be false.

[mirath]

@miniwark

What does this PID cache has? I don't see how it would solve the problem that @alficles demostrated with his snippet.

The cache must contain the process PID, which is used to manage and kill the process. The only way to avoid the problem would be to, before handling the process, compare other info attached to the process (ie. command line arguments, user, nice value, etc) with the one in the cache.

[miniwark]

@mirath

I don't know the inner code of psutils so i can't reply exactly, but if i have well understood their docs the psutil.process_iter() utility function would yield a NoSuchProcess exception if we try to work on a process who do not exist any more since the iteration was done.

[alficles]

@mirath Even verification isn't enough to be sure. In the intervening time between verifying the information and killing the process, the pid may have been killed and reused.