[RFC] un petite hack: /proc/*/ctl
diff mbox series

Message ID 20051129002801.GA9785@mipter.zuzino.mipt.ru
State New, archived
Headers show
Series
  • [RFC] un petite hack: /proc/*/ctl
Related show

Commit Message

Alexey Dobriyan Nov. 29, 2005, 12:28 a.m. UTC
echo kill >/proc/$PID/ctl
	send SIGKILL to process

echo term >/proc/$PID/ctl
	send SIGTERM to process


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Comments

Chris Boot Nov. 29, 2005, 12:23 a.m. UTC | #1
On 29 Nov 2005, at 0:28, Alexey Dobriyan wrote:

> echo kill >/proc/$PID/ctl
> 	send SIGKILL to process
>
> echo term >/proc/$PID/ctl
> 	send SIGTERM to process

Pardon me for my ignorance, but what's wrong with the following?

kill -KILL $PID
     and
kill -TERM $PID

Thanks,
Chris
Alexey Dobriyan Nov. 29, 2005, 1:33 a.m. UTC | #2
On Tue, Nov 29, 2005 at 12:23:19AM +0000, Chris Boot wrote:
> On 29 Nov 2005, at 0:28, Alexey Dobriyan wrote:
> >echo kill >/proc/$PID/ctl
> >	send SIGKILL to process
> >
> >echo term >/proc/$PID/ctl
> >	send SIGTERM to process
>
> Pardon me for my ignorance, but what's wrong with the following?
>
> kill -KILL $PID
>     and
> kill -TERM $PID

kill(1) existence. Not that I'm seriously proposing patch for inclusion.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Willy TARREAU Nov. 29, 2005, 5:48 a.m. UTC | #3
On Tue, Nov 29, 2005 at 04:33:54AM +0300, Alexey Dobriyan wrote:
> On Tue, Nov 29, 2005 at 12:23:19AM +0000, Chris Boot wrote:
> > On 29 Nov 2005, at 0:28, Alexey Dobriyan wrote:
> > >echo kill >/proc/$PID/ctl
> > >	send SIGKILL to process
> > >
> > >echo term >/proc/$PID/ctl
> > >	send SIGTERM to process
> >
> > Pardon me for my ignorance, but what's wrong with the following?
> >
> > kill -KILL $PID
> >     and
> > kill -TERM $PID
> 
> kill(1) existence.

This is non sense, kill is included in the shell ! And if you need to
agressively reduce a binary size, a simple call to kill() will be
shorter than sprintf(), open(), write(), close().

> Not that I'm seriously proposing patch for inclusion.

so please don't pollute the list with useless patches that take time
to review.

Regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Willy TARREAU Nov. 29, 2005, 5:53 a.m. UTC | #4
On Tue, Nov 29, 2005 at 06:48:19AM +0100, Willy Tarreau wrote:
> On Tue, Nov 29, 2005 at 04:33:54AM +0300, Alexey Dobriyan wrote:
> > On Tue, Nov 29, 2005 at 12:23:19AM +0000, Chris Boot wrote:
> > > On 29 Nov 2005, at 0:28, Alexey Dobriyan wrote:
> > > >echo kill >/proc/$PID/ctl
> > > >	send SIGKILL to process
> > > >
> > > >echo term >/proc/$PID/ctl
> > > >	send SIGTERM to process
> > >
> > > Pardon me for my ignorance, but what's wrong with the following?
> > >
> > > kill -KILL $PID
> > >     and
> > > kill -TERM $PID
> > 
> > kill(1) existence.
> 
> This is non sense, kill is included in the shell ! And if you need to
> agressively reduce a binary size, a simple call to kill() will be
> shorter than sprintf(), open(), write(), close().
> 
> > Not that I'm seriously proposing patch for inclusion.
> 
> so please don't pollute the list with useless patches that take time
> to review.

Sorry, I've just noticed that you marked the subject "[RFC]" and not
"[PATCH]". Anyway I still find it useless :-)

Regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Denis Vlasenko Nov. 29, 2005, 7:26 a.m. UTC | #5
On Tuesday 29 November 2005 07:53, Willy Tarreau wrote:
> On Tue, Nov 29, 2005 at 06:48:19AM +0100, Willy Tarreau wrote:
> > On Tue, Nov 29, 2005 at 04:33:54AM +0300, Alexey Dobriyan wrote:
> > > On Tue, Nov 29, 2005 at 12:23:19AM +0000, Chris Boot wrote:
> > > > On 29 Nov 2005, at 0:28, Alexey Dobriyan wrote:
> > > > >echo kill >/proc/$PID/ctl
> > > > >	send SIGKILL to process
> > > > >
> > > > >echo term >/proc/$PID/ctl
> > > > >	send SIGTERM to process
> >
> > so please don't pollute the list with useless patches that take time
> > to review.
> 
> Sorry, I've just noticed that you marked the subject "[RFC]" and not
> "[PATCH]". Anyway I still find it useless :-)

It's just fits into "Everything is a file" and 
eliminates the need of a kill syscall.

Needs to be complemented with means to do
kill 0 ("All processesin the current process group are signaled"),
kill -1 ("All processes with pid larger than 1 are signaled") and
kill -n ("All processes in process group n are signaled").
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Folkert van Heusden Nov. 30, 2005, 10:21 a.m. UTC | #6
> > Not that I'm seriously proposing patch for inclusion.
> so please don't pollute the list with useless patches that take time
> to review.

Are you theo de raadt's nephew?


Folkert van Heusden
Willy TARREAU Nov. 30, 2005, 9:23 p.m. UTC | #7
On Wed, Nov 30, 2005 at 11:21:11AM +0100, Folkert van Heusden wrote:
> > > Not that I'm seriously proposing patch for inclusion.
> > so please don't pollute the list with useless patches that take time
> > to review.
> 
> Are you theo de raadt's nephew?

not at all. It's just that patches on the list take more and more time
to check, we're around something like 1 patch for 5 mails. And when the
author himself suggests that the patch is not for inclusion, it wastes
time. However, I agree that Alexey announced it as [RFC] and not [PATCH],
so he proceeded correctly and I was wrong to yell at him (that's why I
apologised when I noticed this). But generally speaking, I do not find
it very constructive to send random work in which even the author does
not believe. It only lowers the SNR.

> Folkert van Heusden

Regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Jan Engelhardt Dec. 9, 2005, 2:24 p.m. UTC | #8
>> > > Not that I'm seriously proposing patch for inclusion.
>> > so please don't pollute the list with useless patches that take time
>> > to review.
>> 
>> Are you theo de raadt's nephew?
>
>not at all. It's just that patches on the list take more and more time
>to check, we're around something like 1 patch for 5 mails. And when the
>author himself suggests that the patch is not for inclusion, it wastes
>time. However, I agree that Alexey announced it as [RFC] and not [PATCH],

Such things should be tagged as [OT] then, they are not worth enough to be 
named [RFC].


Jan Engelhardt
Kyle Moffett Dec. 15, 2005, 3:58 a.m. UTC | #9
On Dec 09, 2005, at 09:24, Jan Engelhardt wrote:
>> not at all. It's just that patches on the list take more and more  
>> time to check, we're around something like 1 patch for 5 mails.  
>> And when the author himself suggests that the patch is not for  
>> inclusion, it wastes time. However, I agree that Alexey announced  
>> it as [RFC] and not [PATCH],
>
> Such things should be tagged as [OT] then, they are not worth  
> enough to be named [RFC].

Just thinking about this a bit more, this does have some practical  
value.  This would allow a process to acquire a "PID handle", such  
that it could later reliably send a signal to this process without  
worrying about any of the traditional PID reuse issues.  This would  
also solve some of the problems of the process checkpointing people.

Cheers,
Kyle Moffett

--
Simple things should be simple and complex things should be possible
   -- Alan Kay



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Patch
diff mbox series

--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -71,6 +71,7 @@ 
 #include <linux/cpuset.h>
 #include <linux/audit.h>
 #include <linux/poll.h>
+#include <linux/syscalls.h>
 #include "internal.h"
 
 /*
@@ -125,6 +126,7 @@  enum pid_directory_inos {
 #endif
 	PROC_TGID_OOM_SCORE,
 	PROC_TGID_OOM_ADJUST,
+	PROC_TGID_CTL,
 	PROC_TID_INO,
 	PROC_TID_STATUS,
 	PROC_TID_MEM,
@@ -165,6 +167,7 @@  enum pid_directory_inos {
 #endif
 	PROC_TID_OOM_SCORE,
 	PROC_TID_OOM_ADJUST,
+	PROC_TID_CTL,
 
 	/* Add new entries before this */
 	PROC_TID_FD_DIR = 0x8000,	/* 0x8000-0xffff */
@@ -220,6 +223,7 @@  static struct pid_entry tgid_base_stuff[
 #ifdef CONFIG_AUDITSYSCALL
 	E(PROC_TGID_LOGINUID, "loginuid", S_IFREG|S_IWUSR|S_IRUGO),
 #endif
+	E(PROC_TGID_CTL,       "ctl",     S_IFREG|S_IWUSR),
 	{0,0,NULL,0}
 };
 static struct pid_entry tid_base_stuff[] = {
@@ -262,6 +266,7 @@  static struct pid_entry tid_base_stuff[]
 #ifdef CONFIG_AUDITSYSCALL
 	E(PROC_TID_LOGINUID, "loginuid", S_IFREG|S_IWUSR|S_IRUGO),
 #endif
+	E(PROC_TID_CTL,        "ctl",     S_IFREG|S_IWUSR),
 	{0,0,NULL,0}
 };
 
@@ -942,6 +947,42 @@  static struct file_operations proc_oom_a
 	.write		= oom_adjust_write,
 };
 
+static ssize_t ctl_write(struct file *file, const char __user *buf,
+			 size_t count, loff_t *ppos)
+{
+	char __buf[5];
+	struct task_struct *task;
+	int sig;
+
+	count = min(count, sizeof(__buf));
+	memset(__buf, 0, sizeof(__buf));
+	if (copy_from_user(__buf, buf, count))
+		return -EFAULT;
+	__buf[sizeof(__buf) - 1] = '\0';
+
+enum {
+	CONFIG_BOFH = 0,
+};
+
+	if (strcmp(__buf, "kill") == 0)
+		sig = SIGKILL;
+	else if (CONFIG_BOFH && strcmp(__buf, "FOAD") == 0)
+		sig = SIGKILL;
+	else if (strcmp(__buf, "term") == 0)
+		sig = SIGTERM;
+	else
+		goto exit;
+
+	task = proc_task(file->f_dentry->d_inode);
+	sys_kill(task->pid, sig);
+exit:
+	return count;
+}
+
+static struct file_operations proc_ctl_operations = {
+	.write		= ctl_write,
+};
+
 static struct inode_operations proc_mem_inode_operations = {
 	.permission	= proc_permission,
 };
@@ -1780,6 +1821,10 @@  static struct dentry *proc_pident_lookup
 		case PROC_TGID_OOM_ADJUST:
 			inode->i_fop = &proc_oom_adjust_operations;
 			break;
+		case PROC_TID_CTL:
+		case PROC_TGID_CTL:
+			inode->i_fop = &proc_ctl_operations;
+			break;
 #ifdef CONFIG_AUDITSYSCALL
 		case PROC_TID_LOGINUID:
 		case PROC_TGID_LOGINUID: