--freezer option to /bin/restart

Serge E. Hallyn serue at us.ibm.com
Sun Mar 28 14:32:54 PDT 2010


Quoting Oren Laadan (orenl at cs.columbia.edu):
> 
> 
> 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?

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

-serge


More information about the Containers mailing list