From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: "Daniel P. Berrange" <berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Linux Containers
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Subject: Re: Mapping between host & container PIDs ?
Date: Tue, 27 Nov 2012 15:49:31 -0600 [thread overview]
Message-ID: <87y5hmhg2c.fsf@xmission.com> (raw)
In-Reply-To: <20121127134759.GL24370-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> (Daniel P. Berrange's message of "Tue, 27 Nov 2012 13:47:59 +0000")
"Daniel P. Berrange" <berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> Thinking about it more generally, this isn't really a container specific
> problem, but rather an issue with the kill() syscall. It is the same
> general class of problem as you see checking file permissions for example,
> which is why you would use fstat() instead of stat() in many cases. It
> might call for a way to get a FD associated with a pid (eg the /proc/$pid
> dir handle) and then be able to kill() via that FD. eg something like
>
>
> dirfd = open("/proc/$pid", O_RDONLY);
>
> exefd = openat(dirfd, "exe", O_RDONLY);
> ...check it is the exe you think it is...
>
> cgroupfd = openat(dirfd, "cgroups", O_RDONLY);
> ...check the process is where you expect it to be...
>
> fkill(dirfd, SIG_KILL)
>
> that's probably a whole can of worms though, so I think i'll just
> restrict myself to killing processes based on the container's view
> of the PID for now.
Yes that is the general solution. It is very reasonable to have a proc
file that you can write to that will send a signal to it's process.
I keep thinking it will be worth implementing one of these days.
Eric
next prev parent reply other threads:[~2012-11-27 21:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-27 10:15 Mapping between host & container PIDs ? Daniel P. Berrange
[not found] ` <20121127101555.GE24370-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-11-27 13:36 ` Serge Hallyn
2012-11-27 13:47 ` Daniel P. Berrange
[not found] ` <20121127134759.GL24370-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-11-27 21:49 ` Eric W. Biederman [this message]
2012-11-27 13:50 ` Eric W. Biederman
[not found] ` <87vccrm9xw.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-11-30 0:43 ` Matt Helsley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y5hmhg2c.fsf@xmission.com \
--to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
--cc=berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.