Linux Container Development
 help / color / mirror / Atom feed
From: Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
To: "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@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:59:14 -0400	[thread overview]
Message-ID: <4BAFD132.7040704@cs.columbia.edu> (raw)
In-Reply-To: <20100328213254.GA12661-r/Jw6+rmf7HQT0dZR+AlfA@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 ?

> 
>>> 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.

  parent reply	other threads:[~2010-03-28 21:59 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 [this message]
     [not found]             ` <4BAFD132.7040704-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2010-03-28 22:33               ` Serge E. Hallyn
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=4BAFD132.7040704@cs.columbia.edu \
    --to=orenl-eqauephvms7envbuuze7ea@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=serue-r/Jw6+rmf7HQT0dZR+AlfA@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