Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1283340
| From | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: Unkillable processes due to PTRACE_TRACEME |
| Date | 2015-12-03 22:00 +0100 |
| Message-ID | <qBJ8S-1Cs-47@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <qloL8-64d-25@gated-at.bofh.it> <qlp4t-6It-1@gated-at.bofh.it> <qlACB-6KM-1@gated-at.bofh.it> <qlAMi-6Wk-33@gated-at.bofh.it> <qlCO7-1qN-25@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi!
> > >> waitid(P_ALL, 0, {}, WNOHANG|WEXITED|WSTOPPED|WCONTINUED, NULL) = 0
> > >>
> > >> So what should be fixed here? Kernel of distro init?
> > >
> > > waitpid(__WALL) indeed joins these processes.
>
> Thanks. And I just checked Fedora 22, it doesn't use __WALL too.
>
> So I think we should change the kernel even if this is not a bug...
> I'll send the patch.
>
> > > But __WALL can't be used with waitid and Ubuntu init uses waitid...
>
> Yes, and I never understood why. Perhaps we should change this too.
>
> > #include <pthread.h>
> > #include <unistd.h>
> > #include <sys/ptrace.h>
> > #include <stdio.h>
> > #include <errno.h>
> > #include <signal.h>
> > #include <sys/types.h>
> > #include <sys/wait.h>
> >
> > void *thr(void *arg) {
> > ptrace(PTRACE_TRACEME, 0, 0, 0);
> > return 0;
> > }
> >
> > int main() {
> > int pid = fork();
> > if (pid == 0) {
> > pthread_t th;
> > pthread_create(&th, 0, thr, 0);
> > sleep(1);
> > return 0;
> > }
> > siginfo_t info = {};
> > int status = 0;
> > int res = waitpid(-1, &status, __WALL);
> > printf("pid=%d res=%d errno=%d\n", pid, res, errno);
> > res = waitpid(-1, &status, __WALL);
> > printf("pid=%d res=%d errno=%d\n", pid, res, errno);
> > return 0;
> > }
> >
> >
> > However, I need to wait for a particular child and if I change the
> > first waitpid to:
> >
> > int res = waitpid(pid, &status, __WALL);
> >
> > then it does not terminate.
> > So how can I wait for such child process?
>
> You can't. This is one of historical oddities. You need to reap the
> traced sub-thread first. And PTRACE_DETACH doesn't work.
If kill -9 does not take out the process, surely that sounds like a
security problem?
I know ptrace is old and tricky and ugly, but ....?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/
Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread
Re: Unkillable processes due to PTRACE_TRACEME Pavel Machek <pavel@ucw.cz> - 2015-12-03 22:00 +0100 Re: Unkillable processes due to PTRACE_TRACEME Oleg Nesterov <oleg@redhat.com> - 2015-12-04 20:10 +0100
csiph-web