--freezer option to /bin/restart

--freezer option to /bin/restart

[Sukadev Bhattiprolu]

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 ?

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 ?

Thanks,

Sukadev

Re: --freezer option to /bin/restart

[Oren Laadan]

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 ?

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

Oren.

Re: --freezer option to /bin/restart

[Serge E. Hallyn]

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?

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

Re: --freezer option to /bin/restart

[Oren Laadan]

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.

Re: --freezer option to /bin/restart

[Serge E. Hallyn]

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.

Re: --freezer option to /bin/restart

[Sukadev Bhattiprolu]

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

If we restart with one of the CLONE_NEW flags like CLONE_NEWPID, a
new cgroup is automatically created right ? So, in effect, all I want
at this point is to be able to leave the restarted application in the
FROZEN state (ie specify the RESTART_FROZEN flag to sys_restart()).

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

Ok. Will add a new field to struct app_restart_args to pass the
RESTART_FROZEN flag to sys_restart(). We can then either add -F option
or allow --freezer without argument to choose this behavior.

Re: --freezer option to /bin/restart

[Serge E. Hallyn]

Quoting Sukadev Bhattiprolu (sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
> >>>> 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 ?
> 
> If we restart with one of the CLONE_NEW flags like CLONE_NEWPID, a
> new cgroup is automatically created right ? So, in effect, all I want

I don't mount ns cgroup, so no, not on my system.

> at this point is to be able to leave the restarted application in the
> FROZEN state (ie specify the RESTART_FROZEN flag to sys_restart()).
> 
> >>
> >> 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.
> 
> Ok. Will add a new field to struct app_restart_args to pass the
> RESTART_FROZEN flag to sys_restart(). We can then either add -F option
> or allow --freezer without argument to choose this behavior.