Quoting Oren Laadan (orenl@xxxxxxxxxxxxxxx): > > > 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 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers