[101001001001]

Why can’t Linux keep track of parent-child relationships and visualize them when you look at running processes? You could instantly identify this virus. And why can’t Linux apps have a universal and straightforward install directory?

[inetknght]

> Why can’t Linux keep track of parent-child relationships and visualize them when you look at running processes?

Linux does keep track of parent-child process relationships. Linux, however, is just a kernel. It's not your operating system and it's definitely not your GUI.

I suggest you look at something like `htop`.

[101001001001]

It doesn’t. See below

[inetknght]

It does. You're mistaking reparenting with another concept: the concept of an absolute parent PID.

The concept of an absolute parent PID is nonsensical. Having an absolute parent PID would reduce the maximum number of processes effectively infinitely by creating a linked list of parent IDs even if the original parent process is gone.

Imagine if PID 2 is a parent process. It spawns a child. The child spawns a child. That child spawns a child... all the way down to the maximum number of PIDs... the final child is PID n. Then, all of the intermediate processes exit.

The final child process with the maximum PID wants to look at its parent process... but it's gone. Now, what do you want the kernel to do?

Should the kernel tell you about that PID n-1? What if another process has been created and has inherited PID n-1? Does your check now think that the process's parent is still alive? Your check is incorrect and will lead to very aggrevating bugs. Should the kernel prevent PID n-1 from being reused? Congrats you've basically just reinvented zombie processes.

No. The solution is to just reparent PID n onto PID 1 and tell you that process is the parent now. Then you, as a developer, have to actually deal with an aspect of computer science: lifetime management of your objects processes. And the kernel is therefore more efficient for the vast majority of processes who don't need or care about their parent.

[cgh]

Assuming you are talking about parent/child processes, use the --forest option in ps for an ascii art process tree.

[souprock]

I implemented the --forest option in ps.

It can't fully work. The kernel forgets parent-child relationships when processes die. Every orphan is adopted by init, and the kernel doesn't bother to remember the original parent. I've always hated this.

Anybody want to fix it?

The simple fix, kind of bad, is to simply remember the number and report it. The trouble here is that the number might get recycled. Adding a boolean to indicate "my original parent died" would help.

The proper fix is to keep some PID values allocated. Do not free a PID value until all the children of it have died. This would mean that every living process without a living original parent would have a ghost parent that gets reported to ps.

Sadly, for compatibility reasons, the getppid() call would need to report the adoptive parent. The fix for this is to add a new system call that reports both the original parent PID and a flag to indicate adoption.

[philsnow]

> The proper fix is to keep some PID values allocated. Do not free a PID value until all the children of it have died.

Any fork bomb at all will exhaust the pid graveyard, wouldn't it? You could change pid_t to 64 bits but then the pid graveyard would take a lot of memory in the kernel.

[souprock]

For an actual fork bomb, nothing ends up in the PID graveyard. No process ever dies. The fork bomb by itself is a problem, even without a PID graveyard. Process limits are required to stop a fork bomb.

For other situations, just keep the direct parents. Worst case, that doubles the PID usage.

[101001001001]

So I was right?

[detaro]

What do you mean by "parent-child relationships"?

[lysium]

Do you mean pstree?