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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox