echo kill >/proc/$PID/ctl
send SIGKILL to process
echo term >/proc/$PID/ctl
send SIGTERM to process
--- 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:
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
--
Chris Boot
[email protected]
http://www.bootc.net/
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.
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
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
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
> > 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
--
Try MultiTail! Multiple windows with logfiles, filtered with regular
expressions, colored output, etc. etc. http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Get your PGP/GPG key signed at http://www.biglumber.com!
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, http://www.vanheusden.com
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
>> > > 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
--
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