[Linux] Issue with process removal logic after calling refresh_process()

[eskarn]

I'm observing an issue with the following scenario:

1. Call refresh_processes()
2. Call refresh_process() on a running process P
3. Kill the process P
4. Call refresh_processes()
5. Call processes() to get the list of running processes

The result of step 5 is incorrect because it still contains the killed process P but only if step 2 is executing, otherwise the result is correct.

I'm not sure if this intended behavior, but to me this seems like a logic issue in this code :

sysinfo/src/linux/system.rs

Line 449 in a0b2467

p.updated = false;

Calling refresh_process is equivalent to calling refresh_processes_specifics(ProcessRefreshKind::everything()), so it triggers refresh_kind.cpu(), and we never set the updated status of the process to false.

This in turn, prevents the process from being removed from the list here (only for the next refresh_processes call):

sysinfo/src/linux/system.rs

Line 213 in a0b2467

if !proc_.updated {

I currently workaround this by using instead ProcessRefreshKind::everything().without_cpu(), but it seems calling refresh_process should never alter the result of the following call to refresh_processes with any RefreshKind.

[GuillaumeGomez]

This is definitely a bug. I'll add a test with this scenario to ensure the killed process doesn't show up.

[GuillaumeGomez]

So interestingly enough, if it's a child from your current process and you kill it, you need to wait for it otherwise it'll stay around with a "zombie" status until the current process is dead. I made some clean up and added tests to enforce it.