From: "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
Cc: Containers
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
Sukadev Bhattiprolu
<sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Subject: Re: --freezer option to /bin/restart
Date: Sun, 28 Mar 2010 17:33:19 -0500 [thread overview]
Message-ID: <20100328223319.GA17523@us.ibm.com> (raw)
In-Reply-To: <4BAFD132.7040704-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):
>
>
> Serge E. Hallyn wrote:
> >Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):
> >>
> >>Sukadev Bhattiprolu wrote:
> >>>The help message for --freezer=CGROUP option says:
> >>>
> >>> freeze tasks in freezer group CGROUP on success
> >>>
> >>>and if this option specifies an existing cgroup, then (and only
> >>>then) is the RESTART_FROZEN flag to sys_restart() set.
> >>>
> >>>Does the --freezer option have to specify an existing cgroup ?
> >>As it is now - yes;
> >>
> >>In theory I would like use -F (--freezer) without an argument,
> >>to use RESTART_FROZEN without explicitly adding tasks to a
> >>target cgroup.
> >>
> >>The trick is that we need to put all the restarted tasks in the
> >>traget cgroup. The coordinator must remain outside that cgroup,
> >>or it will be frozen as well when restart succeeds.
> >>
> >>This means that restarted tasks (at least the root task) have
> >>to be explicitly added to the cgroup - which is why I require
> >>that the cgroup name be passed.
> >>
> >>This could be avoided if we could add 'restart' to a cgruop and
> >>then after spawning the entire tree, we could remove 'restart'
> >>from that cgroup. I don't think this is possible ?
> >
> >Why not? You can certainly move to freezer:/restart.XYZ, spawn
> >tasks, then move back to freezer:/. And since the tasks should
> >hang in sys_restart() until the coordinator calls sys_restart()
> >itself, there should be no race issues. Do you mean that something
> >else won't work?
>
> No, I just wasn't thinking right...
>
> But even in this case, we need some more wisdom: we need to know
> where the coordinator starts (in which cgroup) before moving it
> to a new cgroup, so we can put it back in the original cgroup. Is
> there an API for that ?
Yup - cat /proc/self/cgroup, or I suspect the libcgroup API gives
you a friendlier interface (so you don't have to parse the file
yourself).
> >>>Is there a way to specify that the restarted application belong
> >>>to a new (yet-to-be created) cgroup AND to leave the application
> >>>FROZEN after restart ? Or would we need a new command line option
> >>>and field in 'struct app_restart_args' to specify this ?
> >>This is exactly what --freezer does. Well, alsmot - except for
> >>"yet-to-be created". Do you want 'restart' to create the cgroup
> >>if it doesn't exist ?
> >
> >I thought that was what Suka was asking for.
>
> If he wants to add it to the 'restart' utility, then sure, with
> a proper argument.
>
> I'm not sure that creating a control group fits into the mandate
> of a library call/api. Instead, I'd expect the caller to arrange
> for a cgroup to be created.
>
> Oren.
next prev parent reply other threads:[~2010-03-28 22:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-27 19:14 --freezer option to /bin/restart Sukadev Bhattiprolu
[not found] ` <20100327191453.GA1533-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-03-28 15:16 ` Oren Laadan
[not found] ` <4BAF72C6.1020806-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2010-03-28 21:32 ` Serge E. Hallyn
[not found] ` <20100328213254.GA12661-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-03-28 21:59 ` Oren Laadan
[not found] ` <4BAFD132.7040704-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2010-03-28 22:33 ` Serge E. Hallyn [this message]
2010-03-29 19:56 ` Sukadev Bhattiprolu
[not found] ` <20100329195637.GA26618-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-03-29 20:20 ` Serge E. Hallyn
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=20100328223319.GA17523@us.ibm.com \
--to=serue-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org \
--cc=sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@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