Filter by process id
sgtcortez opened this issue · 17 comments
Would be useful to filter network activity by process identifier.
For example, would be nice to filter only my desired processes running on my machine.
$ nethogs -P <pid> -P <pid>
I would like to implement, if you dont mind
Sure! Remember to make sure it's still efficient for users that do not pass any -P
;)
For sure!
@raboof just one question.
With this feature, the user can filter by process ids ... so, a question that comes to my mind is:
Do I need to aggregate the child process to sum up ?
For example, ./src/nethogs -P 123
, at the start of the nethogs, the pid does not have child processes, but, since it is running, it might create new child processes. I have seen the code, and, I havent seen nothing that aggregates the child with the parent ...
Am I right?
With this feature, if the user select a pid, which creates children processes, it might loose(because, we do not follow children creation). So, it might look confuse ...
If I am right, we might consider adding a new flag, something like: -F(to follow child processes creation). Then, when using -P, we sum the children with the parent, so, we have just one process to show, which, is the sum of all the hierarchy.
I have seen the code, and, I havent seen nothing that aggregates the child with the parent... Am I right?
That's correct
if the user select a pid, which creates children processes, it might loose(because, we do not follow children creation). So, it might look confuse
I see what you mean. I think other tools, like top
, have the same problem, so having -p
might already be a useful feature even without tracking child process creation.
In fact, I'm not sure adding -F
would be worth the added complexity, though if you want to try it I'm happy to at least consider it.
I have one more question @raboof .
I am implementing the filter, but, some questions come to my mind ...
When the user wants to filter some pids, he will use: nethogs -P 123 -P 222 -P 666
, so, we print just those three processes if there is network traffic. The other processes that have network traffic goes to tcp/udp unknown.
But, if all those processes(which the user choose to track) exit(normally, or by the kernel).
What do you think that nethogs should do when, the users wants to filter by pids, than, ALL those pids do not exist anymore?
Should nethogs exit too?
Or
Should nethogs continue to work, then, showing the process normally(as is no -P flag was used at process start) ?
Should nethogs exit too?
For me, this one makes more sense.
When the user wants to filter some pids, he will use:
nethogs -P 123 -P 222 -P 666
, so, we print just those three processes if there is network traffic. The other processes that have network traffic goes to tcp/udp unknown.
Makes sense to me I suppose
But, if all those processes(which the user choose to track) exit(normally, or by the kernel).
What do you think that nethogs should do when, the users wants to filter by pids, than, ALL those pids do not exist anymore?
Should nethogs exit too?
I'm not against that, as long as we don't exit when the processes are running, even if they're not producing any traffic right now.
Or Should nethogs continue to work, then, showing the process normally(as is no -P flag was used at process start) ?
I agree that wouldn't make sense.
It would also be fine to me if nethogs would just keep running, showing all traffic as 'tcp/udp unknown'.
I'm not against that, as long as we don't exit when the processes are running, even if they're not producing any traffic right now.
Makes sense! My first alternative was to remove the pid when it would receive a timeout from: remove_timed_out_processes
.
But, you are right, the process can be waiting for some I/O, and then, no receive/send network traffic. In this, case, I would remove the pid, and, do not track it anymore. Which, is not what the user wants when filtering for a pid.
But, to make this happen, I would need some notification mechanism from the operating system, to notify me when a pid exits. I thought I could do a poll to /proc/<pid>
, but, the process can exit, and then, the operating system might create another process from another program with the same pid. Which, would make the stats showed by nethogs wrong ...
I am looking for something to achieve this behavior.
the process can exit, and then, the operating system might create another process from another program with the same pid. Which, would make the stats showed by nethogs wrong ...
What would you want to happen in this case? Ideally nethogs should show the traffic, under the pid, right?
I think already right now, nethogs will show the wrong command when a pid is re-used within the cache timeout of the pid data.
I think already right now, nethogs will show the wrong command when a pid is re-used within the cache timeout of the pid data.
This might happen ...
I would need something to notify when when the process exits. But, I do not know if Linux has something like this ...
I tried to create a watcher watching the /proc/<pid>
directory, but, as notify informs, it has limitations with pseudo file systems like /proc
.
Inotify reports only events that a user-space program triggers
through the filesystem API. As a result, it does not catch
remote events that occur on network filesystems. (Applications
must fall back to polling the filesystem to catch such events.)
Furthermore, various pseudo-filesystems such as /proc, /sys, and
/dev/pts are not monitorable with inotify.
So, as an alternative, I am using the kill when the process is too much time without network IO. But again, the problem with pid reuse can still happen with this.
This is what I have for now to track the process exit.
void remove_timed_out_processes() {
ProcList *previousproc = NULL;
... Current Code
if ( !(pidsToWatch.empty()) ) {
pid_t process_id = p_todelete->pid;
// The process exitted. So, we need to remove it from our pid list
if ( !(process_exists(process_id)) ) {
if (DEBUG)
std::cout << "The process " << process_id << " does not exist anymore ..." << std::endl;
pidsToWatch.erase(process_id);
}
}
delete todelete;
delete p_todelete;
}
previousproc = curproc;
}
}
bool process_exists(pid_t pid) {
// No signal is sent! Existance is checked only
return kill(pid, 0) != -1;
}
I think already right now, nethogs will show the wrong command when a pid is re-used within the cache timeout of the pid data.
This might happen ... I would need something to notify when when the process exits. But, I do not know if Linux has something like this ... I tried to create a watcher watching the
/proc/<pid>
directory, but, as notify informs, it has limitations with pseudo file systems like/proc
.
I guess the question is: is this really a problem? If you ask nethogs to watch pid X, perhaps it's fine that it first monitors one process with pid X, and then when that process exits and another process is started with the same pid, nethogs monitors that new one?
If you ask nethogs to watch pid X, perhaps it's fine that it first monitors one process with pid X, and then when that process exits and another process is started with the same pid, nethogs monitors that new one?
I do not see this as a problem if we document this behavior ...
That sounds reasonable to me!
Okey! I will update the Readme about this new feature and pointing this behavior.