--freezer option to /bin/restart
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
A message that is not in the archive (sent off-list or not yet received): 20100327191453.GA1533-r/[email protected]
Quoted 8 lines · 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_FROZENflag tosys_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 ?
Quoted 5 lines
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.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 22 lines · Oren Laadan
Quoted 8 lines · 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_FROZENflag tosys_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_FROZENwithout 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.
Quoted 7 lines
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?
Quoted 8 lines
Quoted 4 lines
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
A message that is not in the archive (sent off-list or not yet received): 20100328213254.GA12661-r/[email protected]
Quoted 29 lines · Serge E. Hallyn
Quoted 20 lines · Oren Laadan
Quoted 8 lines · 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_FROZENflag tosys_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_FROZENwithout 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.
Quoted 7 lines
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 ?
Quoted 5 lines
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 callssys_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 ?
Quoted 10 lines
Quoted 8 lines
Quoted 5 lines
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.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 38 lines · Oren Laadan
Quoted 29 lines · Serge E. Hallyn
Quoted 20 lines · Oren Laadan
Quoted 8 lines · 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_FROZENflag tosys_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_FROZENwithout 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.
Quoted 7 lines
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 ?
Quoted 5 lines
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 callssys_restart()itself, there should be no race issues. Do you mean that something else won't work?
Quoted 6 lines
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).
Quoted 18 lines
Quoted 9 lines
Quoted 7 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 4 lines
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()).
Quoted 5 lines
Quoted 2 lines
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.
A message that is not in the archive (sent off-list or not yet received): 20100329195637.GA26618-r/[email protected]
Quoted 10 lines · Sukadev Bhattiprolu
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 4 lines
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_NEWflags likeCLONE_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.
Quoted 12 lines
at this point is to be able to leave the restarted application in the FROZEN state (ie specify the
RESTART_FROZENflag tosys_restart()).Quoted 5 lines
Quoted 2 lines
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_argsto pass theRESTART_FROZENflag tosys_restart(). We can then either add -F option or allow --freezer without argument to choose this behavior.