[Devel] Re: [PATCH 1/3] cgroup : add clone_children control file
On Sat, Sep 4, 2010 at 12:31 AM, Daniel Lezcano daniel.lezc...@free.fr wrote:
@@ -229,6 +229,7 @@ inline int cgroup_is_removed(const struct cgroup *cgrp)
/* bits in struct cgroupfs_root flags field */
enum {
ROOT_NOPREFIX, /* mounted subsystems have no named prefix */
+ ROOT_CLONE_CHILDREN, /* mounted subsystems will inherit from parent */
};
This bit is awkward - you're storing the original value of the
clone_children flag to report in the mount options, but this isn't
necessarily the current state. Might it be better to not store this
and just report the current value of the root cgroup's
CGRP_CLONE_CHILDREN flag?
Paul
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 2/3] cgroup : make the mount options parsing more accurate
On Sat, Sep 4, 2010 at 12:31 AM, Daniel Lezcano daniel.lezc...@free.fr wrote: The actual code does not detect 'all' with one subsystem name, which is IMHO mutually exclusive and when an option is specified even if it is not a subsystem name, we have to specify the 'all' option with the other option. eg: not detected : mount -t cgroup -o all,freezer cgroup /cgroup not flexible : mount -t cgroup -o noprefix,all cgroup /cgroup This patch fix this and makes the code a bit more clear by replacing 'else if' indentation by 'continue' blocks in the loop. Can you fix this description to be clearer about the new behaviour of the code? Reviewed-by: Paul Menage men...@google.com ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] C/R and stdio redirection
Suppose we create a container and redirect its stdout/stderr as follows: lxc-execute -name foo -- /path/to/app /tmp/xyz.out 21 If we attempt to checkpoint the container 'foo', we fail bc one of the fds in the application refers to /tmp/xyz.out, which is also in use outside the container (specifically sys_checkpoint() fails due to the alien mount ns check in ckpt_fill_fname()). It can be argued, 'foo' is not a strict container (since it shares the fd with another container). For this reason, we currently need the CHECKPOINT_SUBTREE flag in lxc-checkpoint. We initially thought that solving mount-namespaces will solve this, but realized that they are both separate problems. Mount-namespace C/R addresses preserving the mounts within the container and /tmp/xyz.out is outside the container. So if an application container needs to redirect stdio as above, we should either a) disable/ignore the alien-mount-ns check or b) try and start the application something like: $ cat /tmp/wrapper /path/to/app /tmp/xyz.out 21 $ lxc-execute --name foo -- /tmp/wrapper with the difference being /tmp/xyz.out is now inside the container's /tmp filesystem rather than in the parent container. Maybe we can go with approach 'a' above only if CHECKPOINT_SUBTREE is also set - we had discussed this before and considered it hacky. Or are there other solutions to this stdio redirection issue ? Thanks, Sukadev ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 2/3] cgroup : make the mount options parsing more accurate
On 09/07/2010 09:38 PM, Paul Menage wrote: On Sat, Sep 4, 2010 at 12:31 AM, Daniel Lezcanodaniel.lezc...@free.fr wrote: The actual code does not detect 'all' with one subsystem name, which is IMHO mutually exclusive and when an option is specified even if it is not a subsystem name, we have to specify the 'all' option with the other option. eg: not detected : mount -t cgroup -o all,freezer cgroup /cgroup not flexible : mount -t cgroup -o noprefix,all cgroup /cgroup This patch fix this and makes the code a bit more clear by replacing 'else if' indentation by 'continue' blocks in the loop. Can you fix this description to be clearer about the new behaviour of the code? Reviewed-by: Paul Menagemen...@google.com Sure no problem. Thanks for the review. -- Daniel ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 1/3] cgroup : add clone_children control file
On 09/07/2010 09:34 PM, Paul Menage wrote:
On Sat, Sep 4, 2010 at 12:31 AM, Daniel Lezcanodaniel.lezc...@free.fr
wrote:
@@ -229,6 +229,7 @@ inline int cgroup_is_removed(const struct cgroup *cgrp)
/* bits in struct cgroupfs_root flags field */
enum {
ROOT_NOPREFIX, /* mounted subsystems have no named prefix */
+ ROOT_CLONE_CHILDREN, /* mounted subsystems will inherit from parent
*/
};
This bit is awkward - you're storing the original value of the
clone_children flag to report in the mount options, but this isn't
necessarily the current state. Might it be better to not store this
and just report the current value of the root cgroup's
CGRP_CLONE_CHILDREN flag?
Sure. Shall I do the same as the release agent mount option ?
Thanks
-- Daniel
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 1/3] cgroup : add clone_children control file
On Tue, Sep 7, 2010 at 1:23 PM, Daniel Lezcano daniel.lezc...@free.fr wrote: This bit is awkward - you're storing the original value of the clone_children flag to report in the mount options, but this isn't necessarily the current state. Might it be better to not store this and just report the current value of the root cgroup's CGRP_CLONE_CHILDREN flag? Sure. Shall I do the same as the release agent mount option ? I think so - the slight problem with this new flag is that it's possible for the root cgroup to have one setting for clone_children and all its children to have a different setting. But I guess we can live with that. (Or maybe simply not make the default clone_children value a mount option, but require it to be set on the root cgroup after mounting?) Paul ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 1/3] cgroup : add clone_children control file
On 09/07/2010 10:26 PM, Paul Menage wrote: On Tue, Sep 7, 2010 at 1:23 PM, Daniel Lezcanodaniel.lezc...@free.fr wrote: This bit is awkward - you're storing the original value of the clone_children flag to report in the mount options, but this isn't necessarily the current state. Might it be better to not store this and just report the current value of the root cgroup's CGRP_CLONE_CHILDREN flag? Sure. Shall I do the same as the release agent mount option ? I think so - the slight problem with this new flag is that it's possible for the root cgroup to have one setting for clone_children and all its children to have a different setting. But I guess we can live with that. (Or maybe simply not make the default clone_children value a mount option, but require it to be set on the root cgroup after mounting?) The clone_children option behaves like the release-agent mount option no ? We can mount with a specific release agent and change it at runtime. IMHO it would be better to give a chance to the administrator to set its system with the mount option instead of force him to write post mount scripts. An alternative would be to set this cgroup option *only* via the mount option, but I am not sure it is good as it may be an unresolvable constraint for a system wanting to use the cgroups with and without this option (same kind of constraint we have with the ns_cgroup). I am favorable to keep the mount option and the ability to change it for another cgroup. -- Daniel ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 1/3] cgroup : add clone_children control file
On Tue, Sep 7, 2010 at 2:13 PM, Daniel Lezcano daniel.lezc...@free.fr wrote: The clone_children option behaves like the release-agent mount option no ? Not quite, since it can be controlled on a per-cgroup basis. We can mount with a specific release agent and change it at runtime. IMHO it would be better to give a chance to the administrator to set its system with the mount option instead of force him to write post mount scripts. An alternative would be to set this cgroup option *only* via the mount option, but I am not sure it is good as it may be an unresolvable constraint for a system wanting to use the cgroups with and without this option (same kind of constraint we have with the ns_cgroup). I am favorable to keep the mount option and the ability to change it for another cgroup. OK, lets mostly keep the current patch, but lose the flag stored at mount-time and just report the mount option based on the current value of the root cgroup's flag. Paul ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 1/3] cgroup : add clone_children control file
On 09/07/2010 11:22 PM, Paul Menage wrote: On Tue, Sep 7, 2010 at 2:13 PM, Daniel Lezcanodaniel.lezc...@free.fr wrote: The clone_children option behaves like the release-agent mount option no ? Not quite, since it can be controlled on a per-cgroup basis. We can mount with a specific release agent and change it at runtime. IMHO it would be better to give a chance to the administrator to set its system with the mount option instead of force him to write post mount scripts. An alternative would be to set this cgroup option *only* via the mount option, but I am not sure it is good as it may be an unresolvable constraint for a system wanting to use the cgroups with and without this option (same kind of constraint we have with the ns_cgroup). I am favorable to keep the mount option and the ability to change it for another cgroup. OK, lets mostly keep the current patch, but lose the flag stored at mount-time and just report the mount option based on the current value of the root cgroup's flag. Ok, will resend a new version. Thanks for reviewing the patchset. -- Daniel ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] vzmigrate for PermitRootLogin=no
i wasn't willing to enable PermitRootLogin, so i added a sudo feature to my copy of vzmigrate, to gain root on the target server via sudo. is this of any interest to others? ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
