From: BlaisorBlade <bla...@ya...> - 2004-10-18 19:17:41
|
On Monday 18 October 2004 19:39, Gerd Knorr wrote: > Lorenzo Colitti <lo...@co...> writes: > > Using a 2.6.8.1 UML kernel on a 2.6.9-rc3 host in tt mode, my "linux" > > processes on the host hang around forever, even if I shut the virtual > > machine down with halt. > > P.S. Might this be due to a change to ptrace committed in 2.6.9rc1? > > There's something about ptrace_stop in this changelog: > > http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/old/patch-2.6.9-rc1 > >-bk16.log > Yes, I see that as well, it actually *is* that ptrace change added in > patch-2.6.9-rc1-bk16. > IMHO it is a bug, I've reported it to lkml a > few days ago, no response yet. Oh well, did I lost it or you did not CC the UML mailing list? And in the 2nd case, why? I'm downloading the patches from BitKeeper. This are the links (not guaranted to work, I should have used "bookmarkable link" but I may have missed some ones): http://linux.bkbits.net:8080/linux-2.5/cset@413f1c0bviEp6fHuuZpUWED2M7lWWA?nav=index.html| tags|ChangeSet@..1.1867 http://linux.bkbits.net:8080/linux-2.5/cset@413f1c00MHeKsQfqBGA5McsDQ71Rmg?nav=index.html| tags|ChangeSet@..1.1867 http://linux.bkbits.net:8080/linux-2.5/cset@413f1bdabfaQNzIZpU6bPxNlSxdriQ?nav=index.html| tags|ChangeSet@..1.1867 http://linux.bkbits.net:8080/linux-2.5/cset@413f1be9vIHHLGwHUvcNtaZDwKSuig?nav=index.html| tags|ChangeSet@..1.1867 There is one patch in particular mentioning ptrace_stop, but the other ones are related to it, too (except the one about strace catching even invalid syscalls). > Problem is that you can't kill -9 processes any more which are ptraced > _and_ stopped at the same time. Sorry, tried kill -CONT? I'm almost sure it works (tried by both Henrik Normstrod and me, not in this case). > skas mode isn't hit that badly by the bug, it "only" hangs on > shutdown/reboot. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Gerd K. <kr...@by...> - 2004-10-18 21:40:21
Attachments:
1.1832.54.192.diff
ptrace.c
|
> > Yes, I see that as well, it actually *is* that ptrace change added in > > patch-2.6.9-rc1-bk16. > > > IMHO it is a bug, I've reported it to lkml a > > few days ago, no response yet. > > Oh well, did I lost it or you did not CC the UML mailing list? And in the 2nd > case, why? I didn't cc the uml list as it isn't a uml bug, its just that uml triggeres it. > I'm downloading the patches from BitKeeper. I'll attach the offending one for reference, also a short test app showing the buggy behavior. > > Problem is that you can't kill -9 processes any more which are ptraced > > _and_ stopped at the same time. > Sorry, tried kill -CONT? I'm almost sure it works (tried by both Henrik > Normstrod and me, not in this case). IMHO it is a clear bug in the (host) kernel, so I didn't attempt yet to workaround that by playing tricks in the UML kernel. I can't see the bug when reading the patch through, probably the separation of stopped and traced process states triggeres some odd corner case somewhere else in the kernel ... If you send a SIGKILL to the process being stopped & ptraced *nothing* happens. Neither the process is killed nor the ptracing parent is notified. That can't be correct. Gerd -- return -ENOSIG; |
From: BlaisorBlade <bla...@ya...> - 2004-10-18 22:22:50
|
On Monday 18 October 2004 23:26, Gerd Knorr wrote: > > > Yes, I see that as well, it actually *is* that ptrace change added in > > > patch-2.6.9-rc1-bk16. > > > > > > IMHO it is a bug, I've reported it to lkml a > > > few days ago, no response yet. > > > > Oh well, did I lost it or you did not CC the UML mailing list? And in the > > 2nd case, why? > I didn't cc the uml list as it isn't a uml bug, its just that uml > triggeres it. Hmm - trying to fix that or just reverting the patch inside the SKAS patch (or as attached patch) would have been a possible workaround. > > I'm downloading the patches from BitKeeper. > > I'll attach the offending one for reference, also a short test app > showing the buggy behavior. > > > Problem is that you can't kill -9 processes any more which are ptraced > > > _and_ stopped at the same time. > > > > Sorry, tried kill -CONT? I'm almost sure it works (tried by both Henrik > > Normstrod and me, not in this case). > IMHO it is a clear bug in the (host) kernel, so I didn't attempt yet to > workaround that by playing tricks in the UML kernel. I can't see the > bug when reading the patch through, probably the separation of stopped > and traced process states triggeres some odd corner case somewhere else > in the kernel ... > > If you send a SIGKILL to the process being stopped & ptraced *nothing* > happens. Neither the process is killed nor the ptracing parent is > notified. That can't be correct. Can you try using SIGCONT, please? Even the patch changelog clearly says that you must kill -CONT before kill -KILL (actually, a kill -CONT may make the process notice the SIGKILL), and that behaviour can be reproduced, I think, on every kernel version. There has been a thread on this (t-mode processes) on uml-devel. Quite frankly, I do not know the question myself - but people seem to agree that this is a correct behaviour. That said, I'll give a look to the patch. Have you CC'ed the patch author on your report? -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Werner A. <wa...@al...> - 2004-10-19 05:01:13
|
BlaisorBlade wrote: > Can you try using SIGCONT, please? Even the patch changelog clearly says that > you must kill -CONT before kill -KILL That looks like a race condition. If the process manages to enter the same state again before you get to KILL it, even this "advanced" kill is lost. > (actually, a kill -CONT may make the process notice the SIGKILL), That's what works so far, yes. I'm actually no quite certain what this thread is about: it sounds as if this was a new problem, but we've required CONT with KILL in some cases already for a long time. > Quite frankly, I do not know the question myself - but people > seem to agree that this is a correct behaviour. The odd thing is that a process that was ptraced but whose ptracer is long dead *still* needs the CONT. That doesn't look right to me. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa...@al... / /_http://www.almesberger.net/____________________________________________/ |
From: BlaisorBlade <bla...@ya...> - 2004-10-19 15:47:28
|
On Tuesday 19 October 2004 07:00, Werner Almesberger wrote: > BlaisorBlade wrote: > > Can you try using SIGCONT, please? Even the patch changelog clearly says > > that you must kill -CONT before kill -KILL > > That looks like a race condition. > If the process manages to enter > the same state again before you get to KILL it, Why? This does not make sense, IMHO - after a SIGCONT it should keep running until something *requests* it stopping - or not? I'm not finding a clue in the sources... it's quite difficult. > even this "advanced" > kill is lost. > > (actually, a kill -CONT may make the process notice the SIGKILL), > That's what works so far, yes. I'm actually no quite certain what > this thread is about: it sounds as if this was a new problem, but > we've required CONT with KILL in some cases already for a long > time. > > Quite frankly, I do not know the question myself - but people > > seem to agree that this is a correct behaviour. > The odd thing is that a process that was ptraced but whose ptracer > is long dead *still* needs the CONT. That doesn't look right to me. I remember that on Slackware, when doing "init 1" it sends even kill -CONT to all processes, so either they think it's correct or they want to workaround an issue existing for lots of kernel releases. Bye -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Werner A. <wa...@al...> - 2004-10-19 16:16:23
|
BlaisorBlade wrote: > Why? This does not make sense, IMHO - after a SIGCONT it should keep running > until something *requests* it stopping - or not? Well, depends on what constellation we have: if the ptracer is already dead, this should work. If the ptracer is still alive, we may return to the same state quickly (e.g. if both sides aren't interactive anyway). Of course, one could argue that, in the latter case, allowing the ptracer to override SIGKILL is a feature (in any case, the ptracer should be able to keep the dying process for examination). Part of the problem is of course that there's no clear and comprehensive definition of what ptrace should do. It would be nice if the POSIX folks would tackle this :) > I'm not finding a clue in the sources... it's quite difficult. Yeah, when I spotted it in 2.5.44, I didn't have the stomach to actually fix it either, and just reported it, hoping that some other brave soul would step up. That was about 1.5 years ago :-( > I remember that on Slackware, when doing "init 1" it sends even kill -CONT to > all processes, so either they think it's correct or they want to workaround > an issue existing for lots of kernel releases. My bet would be on the workaround :-) - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa...@al... / /_http://www.almesberger.net/____________________________________________/ |
From: Gerd K. <kr...@by...> - 2004-10-19 18:20:28
|
On Tue, Oct 19, 2004 at 01:15:53PM -0300, Werner Almesberger wrote: > BlaisorBlade wrote: > > Why? This does not make sense, IMHO - after a SIGCONT it should keep running > > until something *requests* it stopping - or not? > > Well, depends on what constellation we have: if the ptracer is > already dead, this should work. It's alive. > If the ptracer is still alive, we may return to the same state quickly > (e.g. if both sides aren't interactive anyway). Or if the uml kernel scheduler decides the task should go sleep again and sends a SIGSTOP for that ... > Of course, one could argue that, in the latter case, allowing the > ptracer to override SIGKILL is a feature (in any case, the ptracer > should be able to keep the dying process for examination). Yep, but if you want to allow the ptracer override SIGKILL you should at least notify it about the SIGKILL, which doesn't happen either in 2.6.9-rc2+ ... > > I remember that on Slackware, when doing "init 1" it sends even kill > > -CONT to all processes, so either they think it's correct or they > > want to workaround an issue existing for lots of kernel releases. > > My bet would be on the workaround :-) Oh well. As far I can see there is no simple, race-free workaround. Guess we really have to find that damn bug ... Gerd -- return -ENOSIG; |
From: Michael R. <mc...@sa...> - 2004-10-20 23:56:37
|
-----BEGIN PGP SIGNED MESSAGE----- >>>>> "Werner" == Werner Almesberger <wa...@al...> writes: >> Quite frankly, I do not know the question myself - but people >> seem to agree that this is a correct behaviour. Werner> The odd thing is that a process that was ptraced but whose Werner> ptracer is long dead *still* needs the CONT. That doesn't Werner> look right to me. Definitely is WRONG from my point of view. If the tracer goes away, then -9 should work. Principle of least surprise. I tend to believe that -9 should also override being traced as well. I can sort of understand that someone might think they can trace through a -9, but since that signal is never delivered to the process, nor can it be ignored, I can't understand why it matters. Sure, let the ptrace'r know that the process got a -9. - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mc...@xe... http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQXb6sYqHRg3pndX9AQEC/AQAujSBVJh0Qel5I6fJkHTS6YWrCWk7XtQf i8tVsxrxmyE6baWvhfCm/QRZMozxxdQhRA9dIdPEa9/DMewnshAkMG+Ltg8n9q9p QJuKz/6XqbK7locR/48pp96X3y1/4+xdlvb5J276jOwG8wKkYdqlmqvuKD10pn8e aRPPq20vmBM= =/4b6 -----END PGP SIGNATURE----- |
From: Gerd K. <kr...@by...> - 2004-10-21 08:20:28
|
> I tend to believe that -9 should also override being traced as well. > I can sort of understand that someone might think they can trace through > a -9, but since that signal is never delivered to the process, nor can > it be ignored, I can't understand why it matters. > Sure, let the ptrace'r know that the process got a -9. Ok, found a way around that. You can send a SIGKILL, then call PTRACE_CONT, and now the process will see the SIGKILL and die. The patch below fixes it for me for the skas case, not sure about tt through. Gerd Index: linux-uml-2.6.9/arch/um/include/os.h =================================================================== --- linux-uml-2.6.9.orig/arch/um/include/os.h 2004-10-20 10:56:02.000000000 +0200 +++ linux-uml-2.6.9/arch/um/include/os.h 2004-10-20 16:58:00.000000000 +0200 @@ -156,7 +156,7 @@ extern int os_lock_file(int fd, int excl extern unsigned long os_process_pc(int pid); extern int os_process_parent(int pid); extern void os_stop_process(int pid); -extern void os_kill_process(int pid, int reap_child); +extern void os_kill_process(int pid, int reap_child, int trace_cont); extern void os_usr1_process(int pid); extern int os_getpid(void); Index: linux-uml-2.6.9/arch/um/os-Linux/process.c =================================================================== --- linux-uml-2.6.9.orig/arch/um/os-Linux/process.c 2004-10-20 10:55:52.000000000 +0200 +++ linux-uml-2.6.9/arch/um/os-Linux/process.c 2004-10-20 17:16:58.000000000 +0200 @@ -10,6 +10,7 @@ #include <linux/unistd.h> #include <sys/mman.h> #include <sys/wait.h> +#include <sys/ptrace.h> #include "os.h" #include "user.h" #include "user_util.h" @@ -86,12 +87,13 @@ void os_stop_process(int pid) kill(pid, SIGSTOP); } -void os_kill_process(int pid, int reap_child) +void os_kill_process(int pid, int reap_child, int trace_cont) { kill(pid, SIGKILL); - if(reap_child) + if (trace_cont) + ptrace(PTRACE_CONT, pid, NULL, NULL); + if (reap_child) CATCH_EINTR(waitpid(pid, NULL, 0)); - } void os_usr1_process(int pid) Index: linux-uml-2.6.9/arch/um/drivers/port_kern.c =================================================================== --- linux-uml-2.6.9.orig/arch/um/drivers/port_kern.c 2004-10-20 10:55:44.000000000 +0200 +++ linux-uml-2.6.9/arch/um/drivers/port_kern.c 2004-10-20 14:36:10.000000000 +0200 @@ -112,7 +112,7 @@ static int port_accept(struct port_list out_close: os_close_file(fd); if(pid != -1) - os_kill_process(pid, 1); + os_kill_process(pid, 1, 0); out: return(ret); } @@ -262,9 +262,9 @@ void port_remove_dev(void *d) struct port_dev *dev = d; if(dev->helper_pid != -1) - os_kill_process(dev->helper_pid, 0); + os_kill_process(dev->helper_pid, 0, 0); if(dev->telnetd_pid != -1) - os_kill_process(dev->telnetd_pid, 1); + os_kill_process(dev->telnetd_pid, 1, 0); dev->helper_pid = -1; dev->telnetd_pid = -1; } Index: linux-uml-2.6.9/arch/um/drivers/ubd_kern.c =================================================================== --- linux-uml-2.6.9.orig/arch/um/drivers/ubd_kern.c 2004-10-20 10:56:28.000000000 +0200 +++ linux-uml-2.6.9/arch/um/drivers/ubd_kern.c 2004-10-20 14:36:49.000000000 +0200 @@ -470,7 +470,7 @@ static int io_pid = -1; void kill_io_thread(void) { if(io_pid != -1) - os_kill_process(io_pid, 1); + os_kill_process(io_pid, 1, 0); } __uml_exitcall(kill_io_thread); Index: linux-uml-2.6.9/arch/um/drivers/line.c =================================================================== --- linux-uml-2.6.9.orig/arch/um/drivers/line.c 2004-10-20 11:46:34.000000000 +0200 +++ linux-uml-2.6.9/arch/um/drivers/line.c 2004-10-20 14:34:38.000000000 +0200 @@ -638,7 +638,7 @@ static void winch_cleanup(void) os_close_file(winch->fd); } if(winch->pid != -1) - os_kill_process(winch->pid, 1); + os_kill_process(winch->pid, 1, 0); } } __uml_exitcall(winch_cleanup); Index: linux-uml-2.6.9/arch/um/kernel/skas/process.c =================================================================== --- linux-uml-2.6.9.orig/arch/um/kernel/skas/process.c 2004-10-20 11:46:32.000000000 +0200 +++ linux-uml-2.6.9/arch/um/kernel/skas/process.c 2004-10-20 16:33:16.000000000 +0200 @@ -400,7 +400,7 @@ void switch_mm_skas(int mm_fd) void kill_off_processes_skas(void) { #warning need to loop over userspace_pids in kill_off_processes_skas - os_kill_process(userspace_pid[0], 1); + os_kill_process(userspace_pid[0], 1, 1); } void init_registers(int pid) Index: linux-uml-2.6.9/arch/um/kernel/process.c =================================================================== --- linux-uml-2.6.9.orig/arch/um/kernel/process.c 2004-10-20 10:56:58.000000000 +0200 +++ linux-uml-2.6.9/arch/um/kernel/process.c 2004-10-20 16:54:56.000000000 +0200 @@ -141,7 +141,7 @@ static int ptrace_child(void *arg) if(ptrace(PTRACE_TRACEME, 0, 0, 0) < 0){ perror("ptrace"); - os_kill_process(pid, 0); + os_kill_process(pid, 0, 0); } os_stop_process(pid); _exit(os_getpid() == pid); Index: linux-uml-2.6.9/arch/um/kernel/helper.c =================================================================== --- linux-uml-2.6.9.orig/arch/um/kernel/helper.c 2004-10-20 10:56:28.000000000 +0200 +++ linux-uml-2.6.9/arch/um/kernel/helper.c 2004-10-20 16:38:22.000000000 +0200 @@ -45,7 +45,7 @@ static int helper_child(void *arg) errval = errno; printk("execvp of '%s' failed - errno = %d\n", argv[0], errno); os_write_file(data->fd, &errval, sizeof(errval)); - os_kill_process(os_getpid(), 0); + os_kill_process(os_getpid(), 0, 0); return(0); } @@ -106,7 +106,7 @@ int run_helper(void (*pre_exec)(void *), return(pid); out_kill: - os_kill_process(pid, 1); + os_kill_process(pid, 1, 0); out_close: os_close_file(fds[0]); os_close_file(fds[1]); Index: linux-uml-2.6.9/arch/um/kernel/tt/process_kern.c =================================================================== --- linux-uml-2.6.9.orig/arch/um/kernel/tt/process_kern.c 2004-10-20 10:56:57.000000000 +0200 +++ linux-uml-2.6.9/arch/um/kernel/tt/process_kern.c 2004-10-20 16:31:31.000000000 +0200 @@ -66,7 +66,7 @@ void *switch_to_tt(void *prev, void *nex reading = 1; if((from->state == TASK_ZOMBIE) || (from->state == TASK_DEAD)) - os_kill_process(os_getpid(), 0); + os_kill_process(os_getpid(), 0, 0); err = os_read_file(from->thread.mode.tt.switch_pipe[0], &c, sizeof(c)); if(err != sizeof(c)) @@ -82,7 +82,7 @@ void *switch_to_tt(void *prev, void *nex prev_sched = current->thread.prev_sched; if((prev_sched->state == TASK_ZOMBIE) || (prev_sched->state == TASK_DEAD)) - os_kill_process(prev_sched->thread.mode.tt.extern_pid, 1); + os_kill_process(prev_sched->thread.mode.tt.extern_pid, 1, 1); /* This works around a nasty race with 'jail'. If we are switching * between two threads of a threaded app and the incoming process @@ -119,7 +119,7 @@ void release_thread_tt(struct task_struc int pid = task->thread.mode.tt.extern_pid; if(os_getpid() != pid) - os_kill_process(pid, 0); + os_kill_process(pid, 0, 0); } void exit_thread_tt(void) @@ -331,10 +331,10 @@ void kill_off_processes_tt(void) me = os_getpid(); for_each_process(p){ if(p->thread.mode.tt.extern_pid != me) - os_kill_process(p->thread.mode.tt.extern_pid, 0); + os_kill_process(p->thread.mode.tt.extern_pid, 0, 0); } if(init_task.thread.mode.tt.extern_pid != me) - os_kill_process(init_task.thread.mode.tt.extern_pid, 0); + os_kill_process(init_task.thread.mode.tt.extern_pid, 0, 0); } void initial_thread_cb_tt(void (*proc)(void *), void *arg) Index: linux-uml-2.6.9/arch/um/drivers/xterm.c =================================================================== --- linux-uml-2.6.9.orig/arch/um/drivers/xterm.c 2004-10-20 11:46:34.000000000 +0200 +++ linux-uml-2.6.9/arch/um/drivers/xterm.c 2004-10-20 17:01:27.000000000 +0200 @@ -168,10 +168,10 @@ void xterm_close(int fd, void *d) struct xterm_chan *data = d; if(data->pid != -1) - os_kill_process(data->pid, 1); + os_kill_process(data->pid, 1, 0); data->pid = -1; if(data->helper_pid != -1) - os_kill_process(data->helper_pid, 0); + os_kill_process(data->helper_pid, 0, 0); data->helper_pid = -1; os_close_file(fd); } Index: linux-uml-2.6.9/arch/um/kernel/sigio_user.c =================================================================== --- linux-uml-2.6.9.orig/arch/um/kernel/sigio_user.c 2004-10-20 10:57:05.000000000 +0200 +++ linux-uml-2.6.9/arch/um/kernel/sigio_user.c 2004-10-20 16:58:56.000000000 +0200 @@ -259,7 +259,7 @@ static void update_thread(void) fail: sigio_lock(); if(write_sigio_pid != -1) - os_kill_process(write_sigio_pid, 1); + os_kill_process(write_sigio_pid, 1, 0); write_sigio_pid = -1; os_close_file(sigio_private[0]); os_close_file(sigio_private[1]); @@ -386,7 +386,7 @@ void write_sigio_workaround(void) return; out_kill: - os_kill_process(write_sigio_pid, 1); + os_kill_process(write_sigio_pid, 1, 0); write_sigio_pid = -1; out_close2: os_close_file(sigio_private[0]); @@ -419,7 +419,7 @@ int read_sigio_fd(int fd) static void sigio_cleanup(void) { if(write_sigio_pid != -1) - os_kill_process(write_sigio_pid, 1); + os_kill_process(write_sigio_pid, 1, 0); } __uml_exitcall(sigio_cleanup); |
From: Henrik N. <um...@hn...> - 2004-10-19 07:00:25
|
On Tue, 19 Oct 2004, BlaisorBlade wrote: > Can you try using SIGCONT, please? Even the patch changelog clearly says that > you must kill -CONT before kill -KILL (actually, a kill -CONT may make the > process notice the SIGKILL), and that behaviour can be reproduced, I think, > on every kernel version. There has been a thread on this (t-mode processes) > on uml-devel. Quite frankly, I do not know the question myself - but people > seem to agree that this is a correct behaviour. The t-mode thread is about stopped traced processes where the tracing parent have gone away (killed or whatever). There it can be argued if it is sane to delay the SIGKILL only because the process is stopped. It would be more natural to KILL the process in this specific case. If the tracing parent is still alive the natural thing would be to save the signal as pending and notify the parent when the child is restarted. A SIGKILL to a traced process in my opinion should not kill the traced process without allowing the tracing parent to veto on the signal. Regards Henrik |
From: Gerd K. <kr...@by...> - 2004-10-19 07:40:25
|
On Tue, Oct 19, 2004 at 08:59:53AM +0200, Henrik Nordstrom wrote: > If the tracing parent is still alive the natural thing would be to save > the signal as pending and notify the parent when the child is restarted. A > SIGKILL to a traced process in my opinion should not kill the traced > process without allowing the tracing parent to veto on the signal. Well, if you don't ptrace a process you can't catch/veto the SIGKILL as well, so why you should be able to do that while ptracing? Beside that neither the process itself is killed nor the ptracing parent is notified on SIGKILL. When the process is _not_ ptraced the SIGKILL works just fine (unconditionally, no matter whenever the process is stopped or not). IMHO the behavior should be the same when the process is traced. Gerd -- return -ENOSIG; |
From: Henrik N. <um...@hn...> - 2004-10-19 08:47:39
|
On Tue, 19 Oct 2004, Gerd Knorr wrote: > Well, if you don't ptrace a process you can't catch/veto the SIGKILL as > well, so why you should be able to do that while ptracing? You can't, but the tracer can. > Beside that neither the process itself is killed nor the ptracing parent > is notified on SIGKILL. The tracing parent should get notified as soon as it tries to continue the child. If not there is a bug in my opinion. > When the process is _not_ ptraced the SIGKILL works just fine > (unconditionally, no matter whenever the process is stopped or not). Correct. The process is then under the normal UNIX conditions where SIGKILL is unconditional. > IMHO the behavior should be the same when the process is traced. Here I do not agree, but it is my opinion. Regards Henrik |
From: Gerd K. <kr...@by...> - 2004-10-19 09:20:11
|
> >Beside that neither the process itself is killed nor the ptracing parent > >is notified on SIGKILL. > > The tracing parent should get notified as soon as it tries to continue the > child. If not there is a bug in my opinion. Doesn't work as well. Send SIGKILL first, then SIGCONT, nothing happens. Gerd -- return -ENOSIG; |
From: Gerd K. <kr...@by...> - 2004-10-19 07:40:22
|
> Can you try using SIGCONT, please? Even the patch changelog clearly says that > you must kill -CONT before kill -KILL (actually, a kill -CONT may make the > process notice the SIGKILL), and that behaviour can be reproduced, I think, > on every kernel version. Sending the -CONT after -KILL doesn't work. Other way around would be racy ... > That said, I'll give a look to the patch. Have you CC'ed the patch author on > your report? Yes. Gerd -- return -ENOSIG; |