New /proc/pid/kill Interface Proposed For Killing Linux Processes

[phoronix]

Phoronix: New /proc/pid/kill Interface Proposed For Killing Linux Processes

A Google developer has proposed /proc/pid/kill as a new profs-based kill interface for killing a process on Linux...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-Proc-Pid-Kill-RFC

[tildearrow]

Typo:

as a new profs-based kill interface

[torsionbar28]

The principle concern with something like this, is whether it's compatible with psDooM.

[LinAGKar]

Why call it kill if it can send any signal?

[M@yeulC]

So, from what I gathered, it is race-safe as you can use the file descriptor (/proc/pid) as a process handle.

Traditionally, you would use the kill (2) signal on a pid, hoping the process wasn't killed and the pid reused in-between.

I also agree with LinAGKar . I get that the original function.call was named kill, but it might have been a mistake in the first place? (though I can get the consistency argument)

[rmoog]

Phoronix: New /proc/pid/kill Interface Proposed For Killing Linux Processes

A Google developer has proposed /proc/pid/kill as a new profs-based kill interface for killing a process on Linux...

http://www.phoronix.com/scan.php?pag...c-Pid-Kill-RFC

[Emmanuel Deloget]

While I love the GIF, I would say that having a race-condition-free interface to send signals to specific processes is indeed a good thing

[Emmanuel Deloget]

Why call it kill if it can send any signal?

kill (be it the program, the shell builtin or the syscall) has always been able to send any signal to a target process or group of processes. That might be a good reason why the name stuck

[cybertraveler]

I like this idea. It seems like a very graceful solution. However, like LinAGKar was pointing towards; I think it would make more sense to call it "signal" or something like that instead of calling it "kill".

I wonder when procfs will be cleaned up and have all the duplicate functionality from sysfs stripped from it.

[LinAGKar]

kill (be it the program, the shell builtin or the syscall) has always been able to send any signal to a target process or group of processes. That might be a good reason why the name stuck

I understand that the kill command and syscall would need to retain the name for compatability, but if we're making something new we have the opportunity to name it something better. Note also that though the kill command can send any signal, it kills the process by default (well, terminates), so that adds to the case for calling it kill. Here however, you always have to explicitly specify the signal.