Re: [lxc-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace
Gao feng gaof...@cn.fujitsu.com writes: cc libvirt-list On 08/21/2013 01:30 PM, Eric W. Biederman wrote: Gao feng gaof...@cn.fujitsu.com writes: Unix sockets are private resources of net namespace, allowing one net namespace to access to other netns's unix sockets is meaningless. Allowing one net namespace to access another netns's unix socket is deliberate behavior. This is a desired and useful feature, and only a misconfiguration of visible files would allow this to be a problem. I'm researching a problem about shutdown from container, if the cotainer shares the same file /run/systemd/private with host, when we run shutdown -h xxx in container, the shutdown message will be send to the systemd-shutdownd through unix socket /run/systemd/private, and because systemd-shutdownd is running in host, so finally, the host will become shutdown. The simple answer is don't do that then. I can see no reason to share /run outside of the container unless you want this kind of behavior. Quite frankly I want this behavior if I am using network namespaces to support multiple routing contexts. That is if I am using scripts like: ip netns add other ip netns exec other script I don't want to have to remember to say ip netns orig exec shutdown -h now There are more compelling uses and there is no cost in supporting this in the kernel. What kind of misconfiguration caused someone to complain about this? libvirt lxc allows user to set up a container which shares the same root directory with host. seems like the unix sockets whose sun_path is an abstract socket address are net namespace aware. Should we use abstract type of address instead of a file system pathname for systemd in this case? I suspect libvirt should simply not share /run or any other normally writable directory with the host. Sharing /run /var/run or even /tmp seems extremely dubious if you want some kind of containment, and without strange things spilling through. Eric -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace
On 08/21/2013 03:06 PM, Eric W. Biederman wrote: Gao feng gaof...@cn.fujitsu.com writes: cc libvirt-list On 08/21/2013 01:30 PM, Eric W. Biederman wrote: Gao feng gaof...@cn.fujitsu.com writes: Unix sockets are private resources of net namespace, allowing one net namespace to access to other netns's unix sockets is meaningless. Allowing one net namespace to access another netns's unix socket is deliberate behavior. This is a desired and useful feature, and only a misconfiguration of visible files would allow this to be a problem. I'm researching a problem about shutdown from container, if the cotainer shares the same file /run/systemd/private with host, when we run shutdown -h xxx in container, the shutdown message will be send to the systemd-shutdownd through unix socket /run/systemd/private, and because systemd-shutdownd is running in host, so finally, the host will become shutdown. The simple answer is don't do that then. I can see no reason to share /run outside of the container unless you want this kind of behavior. Quite frankly I want this behavior if I am using network namespaces to support multiple routing contexts. That is if I am using scripts like: ip netns add other ip netns exec other script I don't want to have to remember to say ip netns orig exec shutdown -h now There are more compelling uses and there is no cost in supporting this in the kernel. What kind of misconfiguration caused someone to complain about this? libvirt lxc allows user to set up a container which shares the same root directory with host. seems like the unix sockets whose sun_path is an abstract socket address are net namespace aware. Should we use abstract type of address instead of a file system pathname for systemd in this case? I suspect libvirt should simply not share /run or any other normally writable directory with the host. Sharing /run /var/run or even /tmp seems extremely dubious if you want some kind of containment, and without strange things spilling through. right now I only take note of the unix socket /run/systemd/private, but there may have many similar unix sockets, they can exist in any path. the strange problems will still happen. anyway, I will send a patch to setup a fresh tmpfs for the /run directory of container first. Eric, Thanks for your help! -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [systemd-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace
On Wed, Aug 21, 2013 at 11:51:53AM +0200, Kay Sievers wrote: On Wed, Aug 21, 2013 at 9:22 AM, Gao feng gaof...@cn.fujitsu.com wrote: On 08/21/2013 03:06 PM, Eric W. Biederman wrote: I suspect libvirt should simply not share /run or any other normally writable directory with the host. Sharing /run /var/run or even /tmp seems extremely dubious if you want some kind of containment, and without strange things spilling through. Right, /run or /var cannot be shared. It's not only about sockets, many other things will also go really wrong that way. Libvirt already allows the app defining the container config to set private mounts for any directory including /run and /var. If an admin or app wants to run systemd inside a container, it is their responsibility to ensure they setup the filesystem in a suitable manner. Libvirt is not going to enforce use of a private /run or /var, since that's a policy decision for a specific use case. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace
Gao feng gaof...@cn.fujitsu.com writes: right now I only take note of the unix socket /run/systemd/private, but there may have many similar unix sockets, they can exist in any path. the strange problems will still happen. It could just as easily have been a fifo in the filesystem, and the result would have been the same. The network namespace are all about communicating between network namespaces and that is what was allowed here. If you don't want a socket or a fifo or any other file to be used by a container don't give it access to it. It really is that simple. Eric -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] RFC: aliases
Hi Serge, I'm thinking symbolic link may be the simplest thing to support - lxc_container_new() could immediately readlink() to get the real container name. Yes, I agree, I'd find such a thing very useful. However, it should not only be lxc_container_new but also the utilities not using the API, such as lxc-start etc. So the desireable behavior would be, in my eyes: - _Everywhere_, when resolving a container name, see if the configuration directory is a symlink. If it is: - relativ symlink without a /: use destination as effective container name - contains / (relative or absolute): completely resolve path and see if it starts with the configuration directory if not - don't assume anything about the name (i.e. use the supplied one), but do follow symlink if possible (as is currently done) if so - strip configuration directory from path and use the rest as effective container name - When showing names (mostly lxc-ls), always show the real name by default, never the alias. So if /var/lib/lxc contains the following contents foo/ bar/ baz - bar then lxc-ls should only show foo and bar. An additional option for also showing aliases (or only showing aliases) may be useful here. -- Christian -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] LXC and Ubuntu 13.04
Hello I've found the following issue running lxc-start on Ubuntu 13.04: lxc-start: Read-only file system - failed to change apparmor profile to unconfined This happens despite lxc.aa_profile = unconfined being set in the container configuration. What happened was that aa_am_unconfined() was returning false, and investigating why I found that the string returned by aa_get_profile() was unconfined\n/tty1 instead of simply unconfined. So adding this bit of code at the end of aa_get_profile() fixed the issue for me: space = index(buf, '\n'); if (space) *space = '\0'; Has anyone seen this before? I'm not sure if this is a kernel bug (since the profile is being read from /proc) or an lxc bug... I'm using kernel 3.8.0-27-generic and lxc 0.9.0-0ubuntu3.4. There's a second issue: if I add an IPv6 address to the configuration, as in lxc.network.ipv6 = 2001:db8:fedc:abcd::2/80 it used to work on 12.04 but on 13.04 I get the following error: lxc-start 1377083732.942 ERRORlxc_confile - No such file or directory - invalid ipv6 address: 2001:db8:fedc:abcd::2/80 Is this known? Thanks Andre -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/5] cgroup: minor bugfixes so start and attach work again
Hi Serge, Having /lxc makes it much easier to sett what's part of a container vs what's part of a user session or whatever else uses cgroups these days. Note that nothing stops you from simply entering cgroup /lxc by hand before executing a container. Right now the code simply puts you into a child of whichever directory you are in. Advantage is slightly simpler code. May I perhaps take a short step back to see why the change in the current logic was added in the first place? https://github.com/lxc/lxc/commit/b98f7d6ed1b89b6452af4a2b5e27d445e4b3a138 Basically, you want to be able to use nested containers but also isolate the cgroup filesystem because it's not virtualized in the kernel. The current mountcgroups hook [1] (which btw. still assumes /lxc as a prefix) bind-mounts host:/sys/fs/cgroup/$controller/lxc/$name to container:/sys/fs/cgroup/$controller [1] https://github.com/lxc/lxc/blob/staging/hooks/mountcgroups But /proc/.../cgroup still contains the /lxc/$name/$name that is not reachable from within the container. This breaks LXC from within such a container, so that's why you implemented the checks to look for parent cgroup directories until you find your own process. If I think about that further, I think the initial bind-mount logic is already borked. Because if nested LXC breaks in such a way, so will many software that uses cgroups and relies on standard behaviour. I think the correct way for the mountcgroups hook is to do the following: Suppose the container has the cgroup /lxc/foo/foo and we just have the 'cpu' controller available. Initially, /sys/fs/cgroup will be a tmpfs and /sys/fs/cgroup/cpu will contain the cpu controller. LXC recursively creates /sys/fs/cgroup/cpu/lxc/foo. It then runs the mountcgroups hook. The mountcgroups hook should now mount a new tmpfs in $containerroot/sys/fs/cgroup. It should then create the directories for the controllers but *also* subdirectories for the cgroup of the containers, i.e. mount -t tmpfs none $containerroot/sys/fs/cgroup mkdir -p $containerroot/sys/fs/cgroup/cpu/lxc/foo mount -n --bind /sys/fs/cgroup/cpu/lxc/foo \ $containerroot/sys/fs/cgroup/cpu/lxc/foo That way, the following will work: cgpath=$(grep $controller /proc/self/cgroup | cut -d: -f3) ls /sys/fs/cgroup/$controller$cgpath (Note that grepping for cpu will also find cpuset and cpuacct, so don't take this example too literally. ;)) This ensures that also other software will not break because of this. On the other hand, LXC itself (not the mount hook) doesn't really look for /sys/fs/cgroup, it goes through all the mountpoints where a cgroup filesystem has been mounted. This would now find /sys/fs/cgroup/cpu/lxc/foo inside the container and not the expected /sys/fs/cgroup/cpu. But even here, we don't have to guess where the cgroup lies, because /proc/self/mountinfo actually gives us the information necessary to discern that - the 4th field of the file contains the path within the filesystem at that mountpoint. So outside the container you'd have a /proc/self/mountinfo entry like 25 22 0:20 / /sys/fs/cgroup/cpu,cpuacct rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,cpuacct,cpu,clone_children And inside the container it'd look like 48 20 0:20 /lxc/foo /sys/fs/cgroup/cpu/lxc/foo rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,cpuacct,cpu,clone_children So if you look for the cgroup /lxc/foo/bar from inside the container, then you can see that from the mount entry you just have to remove the /lxc/foo (4th entry) before pasting it together with the mount point /sys/fs/cgroup/cpu/lxc/foo (5th entry). If you agree that both things would be worthwhile, I'd be willing to write patches both for the mountcgroups hook and also for the LXC code itself. -- Christian PS: Also, please see my other email as to whether we perhaps should follow in the footsteps of other people and use /machine/foo.lxc instead of /lxc/foo. (But that's orthogonal to this.) -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] LXC and Ubuntu 13.04
Hi Andre, I've found the following issue running lxc-start on Ubuntu 13.04: lxc-start: Read-only file system - failed to change apparmor profile to unconfined I had the same issue when playing around and the following patch that is already merged in staging fixes it: https://github.com/lxc/lxc/commit/626ad11bfee3e12e675f51e92920030a6f383b19 -- Christian -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] RFC: aliases
- When showing names (mostly lxc-ls), always show the real name by default, never the alias. So if /var/lib/lxc contains the following contents foo/ bar/ baz - bar then lxc-ls should only show foo and bar. An additional option for also showing aliases (or only showing aliases) may be useful here. What about just showing an additional information in the lxc-ls output? e.g. # lxc-ls test01 test02 test03 test04 test (alias of test01) -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/5] cgroup: minor bugfixes so start and attach work again
Quoting Christian Seiler (christ...@iwakd.de): ... If I think about that further, I think the initial bind-mount logic is already borked. Because if nested LXC breaks in such a way, so will many software that uses cgroups and relies on standard behaviour. I think the correct way for the mountcgroups hook is to do the following: Suppose the container has the cgroup /lxc/foo/foo and we just have the 'cpu' controller available. Initially, /sys/fs/cgroup will be a tmpfs and /sys/fs/cgroup/cpu will contain the cpu controller. LXC recursively creates /sys/fs/cgroup/cpu/lxc/foo. It then runs the mountcgroups hook. The mountcgroups hook should now mount a new tmpfs in $containerroot/sys/fs/cgroup. It should then create the directories for the controllers but *also* subdirectories for the cgroup of the containers, i.e. mount -t tmpfs none $containerroot/sys/fs/cgroup mkdir -p $containerroot/sys/fs/cgroup/cpu/lxc/foo mount -n --bind /sys/fs/cgroup/cpu/lxc/foo \ $containerroot/sys/fs/cgroup/cpu/lxc/foo I've thought about that (and mentioned it on the list, somewhere...), and previously rejected it. I don't remember what my biggest complaint was, though, odd. If we're going to do this, we should do it soon. Would you have time in the next few days? (BTW, if we're going to throw words like b0rked around, I'd prefer to reserve that for the refusal to implement fake-root in cgroups itself which would allow us to ignore this by treating ourselves as really being inside '/') -serge -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] RFC: aliases
Quoting Christian Seiler (christ...@iwakd.de): Hi Serge, I'm thinking symbolic link may be the simplest thing to support - lxc_container_new() could immediately readlink() to get the real container name. Yes, I agree, I'd find such a thing very useful. However, it should not only be lxc_container_new but also the utilities not using the API, such as lxc-start etc. Heh, lxc-start should be using the API. Egads, several commands which I thought I had converted have NOT in fact been converted. That should be done before we do this. So the desireable behavior would be, in my eyes: - _Everywhere_, when resolving a container name, see if the configuration directory is a symlink. If it is: - relativ symlink without a /: use destination as effective container name - contains / (relative or absolute): completely resolve path and see if it starts with the configuration directory if not - don't assume anything about the name (i.e. use the supplied one), but do follow symlink if possible (as is currently done) if so - strip configuration directory from path and use the rest as effective container name Hm, I was thinking just: Anything but lxc-destroy: readlink if $lxcpath/$lxcname is a symlink lxc-destroy: specifically don't dereference symlink. To implement that, we would rename lxc_container_new() to lxc_container_new_ln() which takes an extra boolean and dereferences the symlink if the boolean is true, have lxc_container_new() call that, and have lxc-destroy call lxc_container_new_ln() with the boolean false. - When showing names (mostly lxc-ls), always show the real name by default, never the alias. So if /var/lib/lxc contains the following contents foo/ bar/ baz - bar then lxc-ls should only show foo and bar. An additional option for also showing aliases (or only showing aliases) may be useful here. Yes, that might require a trivial tweak to the listing logic to ignore symlinks. -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/5] cgroup: minor bugfixes so start and attach work again
Quoting Serge Hallyn (serge.hal...@ubuntu.com): Quoting Christian Seiler (christ...@iwakd.de): ... If I think about that further, I think the initial bind-mount logic is already borked. Because if nested LXC breaks in such a way, so will many software that uses cgroups and relies on standard behaviour. Yeah, sitting on this a bit more, I completely agree with you. Please go ahead if you have time, or let me know if you don't. -serge -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/5] cgroup: minor bugfixes so start and attach work again
Hi Serge, If we're going to do this, we should do it soon. Would you have time in the next few days? Define 'few'. ;) I should be able to do that until Monday (barring any emergencies). (BTW, if we're going to throw words like b0rked around, I'd prefer to reserve that for the refusal to implement fake-root in cgroups itself which would allow us to ignore this by treating ourselves as really being inside '/') Sorry, I didn't mean any insult by that. But yes, virtualized cgroups would obviously be the best solution.[tm] Two technical questions: 1. What about the naming convention? Stick with /lxc/$name or go with /machine/$name.lxc (see prev. email)? Or I could make that configurable? 2. Any objections to implementing the mountcgroups hook in C? Especially if I want to do the cgroup mount point detection right (and not just assume /sys/fs/cgroup) it is going to be a huge pain to do that in shell, whereas in C I could reuse code. -- Christian -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/5] cgroup: minor bugfixes so start and attach work again
Quoting Christian Seiler (christ...@iwakd.de): Hi Serge, If we're going to do this, we should do it soon. Would you have time in the next few days? Define 'few'. ;) I should be able to do that until Monday (barring any emergencies). (BTW, if we're going to throw words like b0rked around, I'd prefer to reserve that for the refusal to implement fake-root in cgroups itself which would allow us to ignore this by treating ourselves as really being inside '/') Sorry, I didn't mean any insult by that. But yes, virtualized cgroups would obviously be the best solution.[tm] Two technical questions: 1. What about the naming convention? Stick with /lxc/$name or go with /machine/$name.lxc (see prev. email)? Or I could make that configurable? $name.lxc or lxc.$name seems good for all cases. It'll benefit unprivileged users also. By /machine/$name.lxc did you actually mean under the /machine group? If we add lxc as a prefix or suffix, do you think that suffices for the grouping? 2. Any objections to implementing the mountcgroups hook in C? Especially if I want to do the cgroup mount point detection right (and not just assume /sys/fs/cgroup) it is going to be a huge pain to do that in shell, whereas in C I could reuse code. Nope - it'll require a hooks/Makefile.am tweak, is all. I was using scripts originally to encourage people to hack on them, but I'm not sure people are doing that anyway. (If we wanted to continue supporting that then we might want to use python) -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] Track snapshot dependencies
On Tue, 20 Aug 2013 14:15:26 -0500
Serge Hallyn serge.hal...@ubuntu.com wrote:
[...]
+static bool mod_rdep(struct lxc_container *c, bool inc)
+{
+ char path[MAXPATHLEN];
+ int ret, v = 0;
+ FILE *f;
+ bool bret = false;
+
+ if (container_disk_lock(c))
+ return false;
+ ret = snprintf(path, MAXPATHLEN, %s/%s/lxc_snapshots,
c-config_path,
+ c-name);
+ if (ret 0 || ret MAXPATHLEN)
+ goto out;
+ f = fopen(path, r);
+ if (f) {
+ ret = fscanf(f, %d, v);
+ fclose(f);
+ if (ret != 1) {
+ ERROR(Corrupted file %s, path);
+ goto out;
+ }
+ }
+ v += inc ? 1 : -1;
+ f = fopen(path, w);
+ if (!f)
+ goto out;
+ fprintf(f, %d\n, v);
+ fclose(f);
Should we check the return value of fclose()? ie. it could fail ENOSPC?
[...]
+static bool add_rdepends(struct lxc_container *c, struct
lxc_container *c0) +{
+ int ret;
+ char path[MAXPATHLEN];
+ FILE *f;
+
+ ret = snprintf(path, MAXPATHLEN, %s/%s/lxc_rdepends,
c-config_path,
+ c-name);
+ if (ret 0 || ret = MAXPATHLEN)
+ return false;
+ f = fopen(path, a);
+ if (!f)
+ return false;
+ fprintf(f, %s\n%s\n, c0-config_path, c0-name);
+ fclose(f);
and here, otherwise
Acked-by: Dwight Engen dwight.en...@oracle.com
--
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] RFC: aliases
On Wed, 21 Aug 2013 07:59:11 -0500 Serge Hallyn serge.hal...@ubuntu.com wrote: Quoting Christian Seiler (christ...@iwakd.de): [...] To implement that, we would rename lxc_container_new() to lxc_container_new_ln() which takes an extra boolean and dereferences the symlink if the boolean is true, have lxc_container_new() call that, and have lxc-destroy call lxc_container_new_ln() with the boolean false. - When showing names (mostly lxc-ls), always show the real name by default, never the alias. So if /var/lib/lxc contains the following contents foo/ bar/ baz - bar then lxc-ls should only show foo and bar. An additional option for also showing aliases (or only showing aliases) may be useful here. Yes, that might require a trivial tweak to the listing logic to ignore symlinks. Hmm, if lxc-ls is the analog of ls, then by default maybe we should do what it does: show links. I do agree though it'd be nice to have an option to differentiate that a name is an alias and not the actual thing, maybe in --fancy?. So would pretty much everything except destroy deref? (ie. info, wait, etc...) Would the glob in monitor apply to the link or the deref'ed name? -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] Track snapshot dependencies
Quoting Dwight Engen (dwight.en...@oracle.com):
On Tue, 20 Aug 2013 14:15:26 -0500
Serge Hallyn serge.hal...@ubuntu.com wrote:
[...]
+static bool mod_rdep(struct lxc_container *c, bool inc)
+{
+ char path[MAXPATHLEN];
+ int ret, v = 0;
+ FILE *f;
+ bool bret = false;
+
+ if (container_disk_lock(c))
+ return false;
+ ret = snprintf(path, MAXPATHLEN, %s/%s/lxc_snapshots,
c-config_path,
+ c-name);
+ if (ret 0 || ret MAXPATHLEN)
+ goto out;
+ f = fopen(path, r);
+ if (f) {
+ ret = fscanf(f, %d, v);
+ fclose(f);
+ if (ret != 1) {
+ ERROR(Corrupted file %s, path);
+ goto out;
+ }
+ }
+ v += inc ? 1 : -1;
+ f = fopen(path, w);
+ if (!f)
+ goto out;
+ fprintf(f, %d\n, v);
+ fclose(f);
Should we check the return value of fclose()? ie. it could fail ENOSPC?
I had thought about it, but note that the dependency tracking is
best-effort. I don't want an lxc-clone to fail bc we couldn't
mark the dependency. Maybe I'm wrong on that, and I should.
What do you think?
[...]
+static bool add_rdepends(struct lxc_container *c, struct
lxc_container *c0) +{
+ int ret;
+ char path[MAXPATHLEN];
+ FILE *f;
+
+ ret = snprintf(path, MAXPATHLEN, %s/%s/lxc_rdepends,
c-config_path,
+ c-name);
+ if (ret 0 || ret = MAXPATHLEN)
+ return false;
+ f = fopen(path, a);
+ if (!f)
+ return false;
+ fprintf(f, %s\n%s\n, c0-config_path, c0-name);
+ fclose(f);
and here, otherwise
Acked-by: Dwight Engen dwight.en...@oracle.com
--
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/5] cgroup: minor bugfixes so start and attach work again
Hi Serge, 1. What about the naming convention? Stick with /lxc/$name or go with /machine/$name.lxc (see prev. email)? Or I could make that configurable? $name.lxc or lxc.$name seems good for all cases. It'll benefit unprivileged users also. By /machine/$name.lxc did you actually mean under the /machine group? If we add lxc as a prefix or suffix, do you think that suffices for the grouping? I was looking at what other people (i.e. libvirt) were doing, see this previous mail of mine: http://article.gmane.org/gmane.linux.kernel.containers.lxc.devel/3999 2. Any objections to implementing the mountcgroups hook in C? Especially if I want to do the cgroup mount point detection right (and not just assume /sys/fs/cgroup) it is going to be a huge pain to do that in shell, whereas in C I could reuse code. Nope - it'll require a hooks/Makefile.am tweak, is all. I was using scripts originally to encourage people to hack on them, but I'm not sure people are doing that anyway. (If we wanted to continue supporting that then we might want to use python) I think scripts are generally a good idea for this, but not in every use case, such as this one. And since the mountcgroups hook might be considered part of 'core' functionality, I also think Python is perhaps not the best choice, especially since LXC only supports Python 3.2+. -- Christian -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] Track snapshot dependencies
On Wed, 21 Aug 2013 10:47:20 -0500
Serge Hallyn serge.hal...@ubuntu.com wrote:
Quoting Dwight Engen (dwight.en...@oracle.com):
On Tue, 20 Aug 2013 14:15:26 -0500
Serge Hallyn serge.hal...@ubuntu.com wrote:
[...]
+static bool mod_rdep(struct lxc_container *c, bool inc)
+{
+ char path[MAXPATHLEN];
+ int ret, v = 0;
+ FILE *f;
+ bool bret = false;
+
+ if (container_disk_lock(c))
+ return false;
+ ret = snprintf(path, MAXPATHLEN, %s/%s/lxc_snapshots,
c-config_path,
+ c-name);
+ if (ret 0 || ret MAXPATHLEN)
+ goto out;
+ f = fopen(path, r);
+ if (f) {
+ ret = fscanf(f, %d, v);
+ fclose(f);
+ if (ret != 1) {
+ ERROR(Corrupted file %s, path);
+ goto out;
+ }
+ }
+ v += inc ? 1 : -1;
+ f = fopen(path, w);
+ if (!f)
+ goto out;
+ fprintf(f, %d\n, v);
+ fclose(f);
Should we check the return value of fclose()? ie. it could fail
ENOSPC?
I had thought about it, but note that the dependency tracking is
best-effort. I don't want an lxc-clone to fail bc we couldn't
mark the dependency. Maybe I'm wrong on that, and I should.
What do you think?
Ahh okay. Well I just saw that everything else in the routine was
checking for errors and failing so it just looked like the fclose() was
missed. I think errors from fclose() are a lot less likely than not
being able to open the file in the first place so I guess we can
ignore them.
This is only done for overlayfs right? And if something does go wrong
it just means refcounts are off? If we fail to mark the dependency but
let the clone go through, then the worst that can happen is the
parent gets removed at some later date and the cloned container fails to
work then?
--
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] RFC: aliases
Hey Serge, I'm not opposed the idea but just trying to understand the motivation behind it. We are doing exactly what you described (daily builds uses somename-date-buildnumber and two symlinks latest and stable points some containers) and I'm just using something like following sudo lxc-clone -o $(basename $(readlink SOMEPATH/latest)) -n SOMEOTHERNAME -s and I'm just wondering does it really worth adding more code for doing that? Cheers, On Tue, Aug 20, 2013 at 4:55 PM, Serge Hallyn serge.hal...@ubuntu.comwrote: Hi, one idea that has been brought up is to support 'aliases'. So if you're locally building a daily pristine container, say at 'c-2013-08-20', you might want to then have a 'c-latest' alias or link pointing to the latest container, so you can always just sudo lxc-clone -o c-latest -n test1 -s The most obvious idea would be to use a symbolic link. However, while that mostly works, it's actually not perfect - lxc_container_new() will be called with the name you passed in (c-latest), not with the symlinked name. Another idea would be to support a $lxcpath/$lxcname/config consisting of only 'lxc.alias = c-2013-0820'. Do people have any other ideas? I'm thinking symbolic link may be the simplest thing to support - lxc_container_new() could immediately readlink() to get the real container name. -serge -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel -- S.Çağlar Onur cag...@10ur.org -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] Track snapshot dependencies
Quoting Dwight Engen (dwight.en...@oracle.com):
On Wed, 21 Aug 2013 10:47:20 -0500
Serge Hallyn serge.hal...@ubuntu.com wrote:
Quoting Dwight Engen (dwight.en...@oracle.com):
On Tue, 20 Aug 2013 14:15:26 -0500
Serge Hallyn serge.hal...@ubuntu.com wrote:
[...]
+static bool mod_rdep(struct lxc_container *c, bool inc)
+{
+ char path[MAXPATHLEN];
+ int ret, v = 0;
+ FILE *f;
+ bool bret = false;
+
+ if (container_disk_lock(c))
+ return false;
+ ret = snprintf(path, MAXPATHLEN, %s/%s/lxc_snapshots,
c-config_path,
+ c-name);
+ if (ret 0 || ret MAXPATHLEN)
+ goto out;
+ f = fopen(path, r);
+ if (f) {
+ ret = fscanf(f, %d, v);
+ fclose(f);
+ if (ret != 1) {
+ ERROR(Corrupted file %s, path);
+ goto out;
+ }
+ }
+ v += inc ? 1 : -1;
+ f = fopen(path, w);
+ if (!f)
+ goto out;
+ fprintf(f, %d\n, v);
+ fclose(f);
Should we check the return value of fclose()? ie. it could fail
ENOSPC?
I had thought about it, but note that the dependency tracking is
best-effort. I don't want an lxc-clone to fail bc we couldn't
mark the dependency. Maybe I'm wrong on that, and I should.
What do you think?
Ahh okay. Well I just saw that everything else in the routine was
checking for errors and failing so it just looked like the fclose() was
missed. I think errors from fclose() are a lot less likely than not
being able to open the file in the first place so I guess we can
ignore them.
No I have run into cases where I hadn't checked fclose() and that was
in fact where it was failing...
I'll go ahead and update :)
This is only done for overlayfs right? And if something does go wrong
Yup
it just means refcounts are off? If we fail to mark the dependency but
let the clone go through, then the worst that can happen is the
parent gets removed at some later date and the cloned container fails to
work then?
Right, which is always the case right now.
Of course it can go the other way, where lxc-destroy refuses to destroy
the container bc we couldn't drop the refcount... (would be weird, but
not impossible) so maybe lxc-destroy -f should ignore the refcount...
my patch did not do that.
--
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] RFC: aliases
Quoting S.Çağlar Onur (cag...@10ur.org): Hey Serge, I'm not opposed the idea but just trying to understand the motivation behind it. We are doing exactly what you described (daily builds uses somename-date-buildnumber and two symlinks latest and stable points some containers) and I'm just using something like following sudo lxc-clone -o $(basename $(readlink SOMEPATH/latest)) -n SOMEOTHERNAME -s and I'm just wondering does it really worth adding more code for doing that? I'm not sure. It might be worth it for users. But it's starting to sound like enough code that it might not be justified. -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] Track snapshot dependencies
On Wed, 21 Aug 2013 12:18:13 -0500
Serge Hallyn serge.hal...@ubuntu.com wrote:
Quoting Dwight Engen (dwight.en...@oracle.com):
On Wed, 21 Aug 2013 10:47:20 -0500
Serge Hallyn serge.hal...@ubuntu.com wrote:
Quoting Dwight Engen (dwight.en...@oracle.com):
On Tue, 20 Aug 2013 14:15:26 -0500
Serge Hallyn serge.hal...@ubuntu.com wrote:
[...]
+static bool mod_rdep(struct lxc_container *c, bool inc)
+{
+ char path[MAXPATHLEN];
+ int ret, v = 0;
+ FILE *f;
+ bool bret = false;
+
+ if (container_disk_lock(c))
+ return false;
+ ret = snprintf(path, MAXPATHLEN,
%s/%s/lxc_snapshots, c-config_path,
+ c-name);
+ if (ret 0 || ret MAXPATHLEN)
+ goto out;
+ f = fopen(path, r);
+ if (f) {
+ ret = fscanf(f, %d, v);
+ fclose(f);
+ if (ret != 1) {
+ ERROR(Corrupted file %s, path);
+ goto out;
+ }
+ }
+ v += inc ? 1 : -1;
+ f = fopen(path, w);
+ if (!f)
+ goto out;
+ fprintf(f, %d\n, v);
+ fclose(f);
Should we check the return value of fclose()? ie. it could fail
ENOSPC?
I had thought about it, but note that the dependency tracking is
best-effort. I don't want an lxc-clone to fail bc we couldn't
mark the dependency. Maybe I'm wrong on that, and I should.
What do you think?
Ahh okay. Well I just saw that everything else in the routine was
checking for errors and failing so it just looked like the fclose()
was missed. I think errors from fclose() are a lot less likely than
not being able to open the file in the first place so I guess we can
ignore them.
No I have run into cases where I hadn't checked fclose() and that was
in fact where it was failing...
I'll go ahead and update :)
This is only done for overlayfs right? And if something does go
wrong
Yup
it just means refcounts are off? If we fail to mark the dependency
but let the clone go through, then the worst that can happen is the
parent gets removed at some later date and the cloned container
fails to work then?
Right, which is always the case right now.
Of course it can go the other way, where lxc-destroy refuses to
destroy the container bc we couldn't drop the refcount... (would be
weird, but not impossible) so maybe lxc-destroy -f should ignore the
refcount... my patch did not do that.
Ahh yeah, thats probably a good idea. They can also get off if people
just rm -rf the container (and I'm guilty of doing that sometimes), so
like you said best effort.
--
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH] lxc_cgroup: convert to using API
Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com
---
src/lxc/lxc_cgroup.c | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/src/lxc/lxc_cgroup.c b/src/lxc/lxc_cgroup.c
index 094686d..7f6eb63 100644
--- a/src/lxc/lxc_cgroup.c
+++ b/src/lxc/lxc_cgroup.c
@@ -29,6 +29,7 @@
#include lxc/lxc.h
#include lxc/log.h
+#include lxc/lxccontainer.h
#include arguments.h
lxc_log_define(lxc_cgroup_ui, lxc_cgroup);
@@ -64,6 +65,7 @@ Options :\n\
int main(int argc, char *argv[])
{
char *state_object = NULL, *value = NULL;
+ struct lxc_container *c;
if (lxc_arguments_parse(my_args, argc, argv))
return -1;
@@ -74,29 +76,36 @@ int main(int argc, char *argv[])
state_object = my_args.argv[0];
- if ((argc) 1)
- value = my_args.argv[1];
+ c = lxc_container_new(my_args.name, my_args.lxcpath[0]);
+ if (!c)
+ return -1;
+ if (!c-is_running(c)) {
+ ERROR('%s:%s' is not running, my_args.lxcpath[0],
my_args.name);
+ lxc_container_put(c);
+ return -1;
+ }
- if (value) {
- if (lxc_cgroup_set(my_args.name, state_object, value,
my_args.lxcpath[0])) {
+ if ((my_args.argc) 1) {
+ value = my_args.argv[1];
+ if (!c-set_cgroup_item(c, state_object, value)) {
ERROR(failed to assign '%s' value to '%s' for '%s',
value, state_object, my_args.name);
+ lxc_container_put(c);
return -1;
}
} else {
- const unsigned long len = 4096;
- int ret;
+ int len = 4096;
char buffer[len];
-
- ret = lxc_cgroup_get(my_args.name, state_object, buffer, len,
my_args.lxcpath[0]);
+ int ret = c-get_cgroup_item(c, state_object, buffer, len);
if (ret 0) {
- ERROR(failed to retrieve value of '%s' for '%s',
- state_object, my_args.name);
+ ERROR(failed to retrieve value of '%s' for '%s:%s',
+ state_object, my_args.lxcpath[0], my_args.name);
+ lxc_container_put(c);
return -1;
}
-
printf(%*s, ret, buffer);
}
+ lxc_container_put(c);
return 0;
}
--
1.8.3.2
--
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] Track snapshot dependencies
Quoting Dwight Engen (dwight.en...@oracle.com): Ahh yeah, thats probably a good idea. They can also get off if people just rm -rf the container (and I'm guilty of doing that sometimes), so like you said best effort. Drat, that would require an API change to pass a flag to destroy. Still might be worth it, but it'll affect all bindings. -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH] Track snapshot dependencies (v2)
(Will push in a bit barring any objections)
lvm, btrfs, and zfs snapshots each do an ok job of handling deletions
for us - a btrfs snapshot does fine after the original is removed,
while zfs and lvm will both refuse to allow the original to be deleted
while the snapshot exists.
Overlayfs doesn't do this for us. So, for overlayfs snapshots, track
the dependencies.
When c2 is created as an overlayfs snapshot of dir-backed c1, then
1. c2's lxc_rdepends file will contain
c1_lxcpath
c1_lxcname
2. c1's lxc_snapshots will contain 1
c1 cannot be deleted so long as lxc_snapshots exists and contains
a non-zero number.
The contents of lxc_snapshots and lxc_rdepends are protected by
container_disk_lock() and at lxc_clone by the new container not yet
being accessible.
(Originally I was going to keep them in the container config, but the
problem with using $lxcpath/$name/config is that api users could end up
calling c-save_config() with a cached old value of snapshots/rdepends.)
Changelog:
aug 21: check for fprintf and fclose failures
Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com
Acked-by: Dwight Engen dwight.en...@oracle.com
---
src/lxc/bdev.c | 8 +-
src/lxc/bdev.h | 3 +-
src/lxc/lxc.h | 5 ++
src/lxc/lxccontainer.c | 209 +
4 files changed, 209 insertions(+), 16 deletions(-)
diff --git a/src/lxc/bdev.c b/src/lxc/bdev.c
index fbc314b..409708d 100644
--- a/src/lxc/bdev.c
+++ b/src/lxc/bdev.c
@@ -1895,7 +1895,8 @@ struct bdev *bdev_init(const char *src, const char *dst,
const char *data)
*/
struct bdev *bdev_copy(const char *src, const char *oldname, const char *cname,
const char *oldpath, const char *lxcpath, const char
*bdevtype,
- int snap, const char *bdevdata, unsigned long newsize)
+ int snap, const char *bdevdata, unsigned long newsize,
+ int *needs_rdep)
{
struct bdev *orig, *new;
pid_t pid;
@@ -1937,6 +1938,11 @@ struct bdev *bdev_copy(const char *src, const char
*oldname, const char *cname,
if (!bdevtype snap strcmp(orig-type , dir) == 0)
bdevtype = overlayfs;
+ *needs_rdep = 0;
+ if (strcmp(orig-type, dir) == 0
+ strcmp(bdevtype, overlayfs) == 0)
+ *needs_rdep = 1;
+
new = bdev_get(bdevtype ? bdevtype : orig-type);
if (!new) {
ERROR(no such block device type: %s, bdevtype ? bdevtype :
orig-type);
diff --git a/src/lxc/bdev.h b/src/lxc/bdev.h
index 1d79bb2..ecd62ee 100644
--- a/src/lxc/bdev.h
+++ b/src/lxc/bdev.h
@@ -81,7 +81,8 @@ struct bdev *bdev_init(const char *src, const char *dst,
const char *data);
struct bdev *bdev_copy(const char *src, const char *oldname, const char *cname,
const char *oldpath, const char *lxcpath, const char
*bdevtype,
- int snap, const char *bdevdata, unsigned long newsize);
+ int snap, const char *bdevdata, unsigned long newsize,
+ int *needs_rdep);
struct bdev *bdev_create(const char *dest, const char *type,
const char *cname, struct bdev_specs *specs);
void bdev_put(struct bdev *bdev);
diff --git a/src/lxc/lxc.h b/src/lxc/lxc.h
index 253c440..4a9eca2 100644
--- a/src/lxc/lxc.h
+++ b/src/lxc/lxc.h
@@ -227,6 +227,11 @@ extern int lxc_container_put(struct lxc_container *c);
*/
extern int lxc_get_wait_states(const char **states);
+/*
+ * Add a dependency to a container
+ */
+extern int add_rdepend(struct lxc_conf *lxc_conf, char *rdepend);
+
#ifdef __cplusplus
}
#endif
diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
index facf9a7..7172c00 100644
--- a/src/lxc/lxccontainer.c
+++ b/src/lxc/lxccontainer.c
@@ -52,6 +52,12 @@
#include ../include/ifaddrs.h
#endif
+#ifndef HAVE_GETLINE
+#ifdef HAVE_FGETLN
+#include ../include/getline.h
+#endif
+#endif
+
lxc_log_define(lxc_container, lxc);
static bool file_exists(char *f)
@@ -1362,6 +1368,121 @@ out:
return ret;
}
+static bool mod_rdep(struct lxc_container *c, bool inc)
+{
+ char path[MAXPATHLEN];
+ int ret, v = 0;
+ FILE *f;
+ bool bret = false;
+
+ if (container_disk_lock(c))
+ return false;
+ ret = snprintf(path, MAXPATHLEN, %s/%s/lxc_snapshots, c-config_path,
+ c-name);
+ if (ret 0 || ret MAXPATHLEN)
+ goto out;
+ f = fopen(path, r);
+ if (f) {
+ ret = fscanf(f, %d, v);
+ fclose(f);
+ if (ret != 1) {
+ ERROR(Corrupted file %s, path);
+ goto out;
+ }
+ }
+ v += inc ? 1 : -1;
+ f = fopen(path, w);
+ if (!f)
+ goto out;
+ if (fprintf(f, %d\n, v) 0) {
+ ERROR(Error writing new
Re: [lxc-devel] [PATCH] lxc_cgroup: convert to using API
On Wed, 21 Aug 2013 14:35:28 -0500
Serge Hallyn serge.hal...@ubuntu.com wrote:
Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com
Acked-by: Dwight Engen dwight.en...@oracle.com
---
src/lxc/lxc_cgroup.c | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/src/lxc/lxc_cgroup.c b/src/lxc/lxc_cgroup.c
index 094686d..7f6eb63 100644
--- a/src/lxc/lxc_cgroup.c
+++ b/src/lxc/lxc_cgroup.c
@@ -29,6 +29,7 @@
#include lxc/lxc.h
#include lxc/log.h
+#include lxc/lxccontainer.h
#include arguments.h
lxc_log_define(lxc_cgroup_ui, lxc_cgroup);
@@ -64,6 +65,7 @@ Options :\n\
int main(int argc, char *argv[])
{
char *state_object = NULL, *value = NULL;
+ struct lxc_container *c;
if (lxc_arguments_parse(my_args, argc, argv))
return -1;
@@ -74,29 +76,36 @@ int main(int argc, char *argv[])
state_object = my_args.argv[0];
- if ((argc) 1)
- value = my_args.argv[1];
+ c = lxc_container_new(my_args.name, my_args.lxcpath[0]);
+ if (!c)
+ return -1;
+ if (!c-is_running(c)) {
+ ERROR('%s:%s' is not running, my_args.lxcpath[0],
my_args.name);
+ lxc_container_put(c);
+ return -1;
+ }
- if (value) {
- if (lxc_cgroup_set(my_args.name, state_object,
value, my_args.lxcpath[0])) {
+ if ((my_args.argc) 1) {
+ value = my_args.argv[1];
+ if (!c-set_cgroup_item(c, state_object, value)) {
ERROR(failed to assign '%s' value to '%s'
for '%s', value, state_object, my_args.name);
+ lxc_container_put(c);
return -1;
}
} else {
- const unsigned long len = 4096;
- int ret;
+ int len = 4096;
char buffer[len];
-
- ret = lxc_cgroup_get(my_args.name, state_object,
buffer, len, my_args.lxcpath[0]);
+ int ret = c-get_cgroup_item(c, state_object,
buffer, len); if (ret 0) {
- ERROR(failed to retrieve value of '%s' for
'%s',
- state_object, my_args.name);
+ ERROR(failed to retrieve value of '%s' for
'%s:%s',
+ state_object, my_args.lxcpath[0],
my_args.name);
+ lxc_container_put(c);
return -1;
}
-
printf(%*s, ret, buffer);
}
+ lxc_container_put(c);
return 0;
}
--
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH] api: convert lxc_wait, lxc_freeze, and lxc_unfreeze
These are the last of the simpler conversions. Start, execute,
kill, info and attach remain to be done.
Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com
---
src/lxc/lxc_freeze.c | 26 ++
src/lxc/lxc_unfreeze.c | 26 ++
src/lxc/lxc_wait.c | 15 ---
3 files changed, 56 insertions(+), 11 deletions(-)
diff --git a/src/lxc/lxc_freeze.c b/src/lxc/lxc_freeze.c
index 3bd5e28..9628e78 100644
--- a/src/lxc/lxc_freeze.c
+++ b/src/lxc/lxc_freeze.c
@@ -28,9 +28,12 @@
#include lxc/lxc.h
#include lxc/log.h
+#include lxc/lxccontainer.h
#include arguments.h
+lxc_log_define(lxc_freeze_ui, lxc_cgroup);
+
static const struct option my_longopts[] = {
LXC_COMMON_OPTIONS
};
@@ -51,13 +54,28 @@ Options :\n\
int main(int argc, char *argv[])
{
+ struct lxc_container *c;
+
if (lxc_arguments_parse(my_args, argc, argv))
- return -1;
+ exit(1);
if (lxc_log_init(my_args.name, my_args.log_file, my_args.log_priority,
my_args.progname, my_args.quiet, my_args.lxcpath[0]))
- return -1;
+ exit(1);
- return lxc_freeze(my_args.name, my_args.lxcpath[0]);
-}
+ c = lxc_container_new(my_args.name, my_args.lxcpath[0]);
+ if (!c) {
+ ERROR(No such container: %s:%s, my_args.lxcpath[0],
my_args.name);
+ exit(1);
+ }
+ if (!c-freeze(c)) {
+ ERROR(Failed to freeze %s:%s, my_args.lxcpath[0],
my_args.name);
+ lxc_container_put(c);
+ exit(1);
+ }
+
+ lxc_container_put(c);
+
+ return 0;
+}
diff --git a/src/lxc/lxc_unfreeze.c b/src/lxc/lxc_unfreeze.c
index 095f290..840467a 100644
--- a/src/lxc/lxc_unfreeze.c
+++ b/src/lxc/lxc_unfreeze.c
@@ -27,9 +27,12 @@
#include lxc/lxc.h
#include lxc/log.h
+#include lxc/lxccontainer.h
#include arguments.h
+lxc_log_define(lxc_unfreeze_ui, lxc_cgroup);
+
static const struct option my_longopts[] = {
LXC_COMMON_OPTIONS
};
@@ -50,13 +53,28 @@ Options :\n\
int main(int argc, char *argv[])
{
+ struct lxc_container *c;
+
if (lxc_arguments_parse(my_args, argc, argv))
- return -1;
+ exit(1);
if (lxc_log_init(my_args.name, my_args.log_file, my_args.log_priority,
my_args.progname, my_args.quiet, my_args.lxcpath[0]))
- return -1;
+ exit(1);
- return lxc_unfreeze(my_args.name, my_args.lxcpath[0]);
-}
+ c = lxc_container_new(my_args.name, my_args.lxcpath[0]);
+ if (!c) {
+ ERROR(No such container: %s:%s, my_args.lxcpath[0],
my_args.name);
+ exit(1);
+ }
+ if (!c-unfreeze(c)) {
+ ERROR(Failed to unfreeze %s:%s, my_args.lxcpath[0],
my_args.name);
+ lxc_container_put(c);
+ exit(1);
+ }
+
+ lxc_container_put(c);
+
+ return 0;
+}
diff --git a/src/lxc/lxc_wait.c b/src/lxc/lxc_wait.c
index f1a065c..afbb81a 100644
--- a/src/lxc/lxc_wait.c
+++ b/src/lxc/lxc_wait.c
@@ -30,7 +30,7 @@
#include lxc/lxc.h
#include lxc/log.h
-#include lxc/monitor.h
+#include lxc/lxccontainer.h
#include arguments.h
lxc_log_define(lxc_wait_ui, lxc_monitor);
@@ -80,6 +80,8 @@ Options :\n\
int main(int argc, char *argv[])
{
+ struct lxc_container *c;
+
if (lxc_arguments_parse(my_args, argc, argv))
return -1;
@@ -87,6 +89,13 @@ int main(int argc, char *argv[])
my_args.progname, my_args.quiet, my_args.lxcpath[0]))
return -1;
- return lxc_wait(strdup(my_args.name), my_args.states, my_args.timeout,
- my_args.lxcpath[0]);
+ c = lxc_container_new(my_args.name, my_args.lxcpath[0]);
+ if (!c)
+ return -1;
+
+ if (!c-wait(c, my_args.states, my_args.timeout)) {
+ lxc_container_put(c);
+ return -1;
+ }
+ return 0;
}
--
1.8.3.2
--
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] api: convert lxc_wait, lxc_freeze, and lxc_unfreeze
On Wed, 21 Aug 2013 16:53:52 -0500
Serge Hallyn serge.hal...@ubuntu.com wrote:
These are the last of the simpler conversions. Start, execute,
kill, info and attach remain to be done.
Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com
Looks good to me
Acked-by: Dwight Engen dwight.en...@oracle.com
---
src/lxc/lxc_freeze.c | 26 ++
src/lxc/lxc_unfreeze.c | 26 ++
src/lxc/lxc_wait.c | 15 ---
3 files changed, 56 insertions(+), 11 deletions(-)
diff --git a/src/lxc/lxc_freeze.c b/src/lxc/lxc_freeze.c
index 3bd5e28..9628e78 100644
--- a/src/lxc/lxc_freeze.c
+++ b/src/lxc/lxc_freeze.c
@@ -28,9 +28,12 @@
#include lxc/lxc.h
#include lxc/log.h
+#include lxc/lxccontainer.h
#include arguments.h
+lxc_log_define(lxc_freeze_ui, lxc_cgroup);
+
static const struct option my_longopts[] = {
LXC_COMMON_OPTIONS
};
@@ -51,13 +54,28 @@ Options :\n\
int main(int argc, char *argv[])
{
+ struct lxc_container *c;
+
if (lxc_arguments_parse(my_args, argc, argv))
- return -1;
+ exit(1);
if (lxc_log_init(my_args.name, my_args.log_file,
my_args.log_priority, my_args.progname, my_args.quiet,
my_args.lxcpath[0]))
- return -1;
+ exit(1);
- return lxc_freeze(my_args.name, my_args.lxcpath[0]);
-}
+ c = lxc_container_new(my_args.name, my_args.lxcpath[0]);
+ if (!c) {
+ ERROR(No such container: %s:%s,
my_args.lxcpath[0], my_args.name);
+ exit(1);
+ }
+ if (!c-freeze(c)) {
+ ERROR(Failed to freeze %s:%s, my_args.lxcpath[0],
my_args.name);
+ lxc_container_put(c);
+ exit(1);
+ }
+
+ lxc_container_put(c);
+
+ return 0;
+}
diff --git a/src/lxc/lxc_unfreeze.c b/src/lxc/lxc_unfreeze.c
index 095f290..840467a 100644
--- a/src/lxc/lxc_unfreeze.c
+++ b/src/lxc/lxc_unfreeze.c
@@ -27,9 +27,12 @@
#include lxc/lxc.h
#include lxc/log.h
+#include lxc/lxccontainer.h
#include arguments.h
+lxc_log_define(lxc_unfreeze_ui, lxc_cgroup);
+
static const struct option my_longopts[] = {
LXC_COMMON_OPTIONS
};
@@ -50,13 +53,28 @@ Options :\n\
int main(int argc, char *argv[])
{
+ struct lxc_container *c;
+
if (lxc_arguments_parse(my_args, argc, argv))
- return -1;
+ exit(1);
if (lxc_log_init(my_args.name, my_args.log_file,
my_args.log_priority, my_args.progname, my_args.quiet,
my_args.lxcpath[0]))
- return -1;
+ exit(1);
- return lxc_unfreeze(my_args.name, my_args.lxcpath[0]);
-}
+ c = lxc_container_new(my_args.name, my_args.lxcpath[0]);
+ if (!c) {
+ ERROR(No such container: %s:%s,
my_args.lxcpath[0], my_args.name);
+ exit(1);
+ }
+ if (!c-unfreeze(c)) {
+ ERROR(Failed to unfreeze %s:%s,
my_args.lxcpath[0], my_args.name);
+ lxc_container_put(c);
+ exit(1);
+ }
+
+ lxc_container_put(c);
+
+ return 0;
+}
diff --git a/src/lxc/lxc_wait.c b/src/lxc/lxc_wait.c
index f1a065c..afbb81a 100644
--- a/src/lxc/lxc_wait.c
+++ b/src/lxc/lxc_wait.c
@@ -30,7 +30,7 @@
#include lxc/lxc.h
#include lxc/log.h
-#include lxc/monitor.h
+#include lxc/lxccontainer.h
#include arguments.h
lxc_log_define(lxc_wait_ui, lxc_monitor);
@@ -80,6 +80,8 @@ Options :\n\
int main(int argc, char *argv[])
{
+ struct lxc_container *c;
+
if (lxc_arguments_parse(my_args, argc, argv))
return -1;
@@ -87,6 +89,13 @@ int main(int argc, char *argv[])
my_args.progname, my_args.quiet,
my_args.lxcpath[0])) return -1;
- return lxc_wait(strdup(my_args.name), my_args.states,
my_args.timeout,
- my_args.lxcpath[0]);
+ c = lxc_container_new(my_args.name, my_args.lxcpath[0]);
+ if (!c)
+ return -1;
+
+ if (!c-wait(c, my_args.states, my_args.timeout)) {
+ lxc_container_put(c);
+ return -1;
+ }
+ return 0;
}
--
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/5] cgroup: minor bugfixes so start and attach work again
Quoting Christian Seiler (christ...@iwakd.de): Hi Serge, 1. What about the naming convention? Stick with /lxc/$name or go with /machine/$name.lxc (see prev. email)? Or I could make that configurable? $name.lxc or lxc.$name seems good for all cases. It'll benefit unprivileged users also. By /machine/$name.lxc did you actually mean under the /machine group? If we add lxc as a prefix or suffix, do you think that suffices for the grouping? I was looking at what other people (i.e. libvirt) were doing, see this previous mail of mine: http://article.gmane.org/gmane.linux.kernel.containers.lxc.devel/3999 Ok, how about we make the system-cgroup-dir configurable in /etc/lxc/lxc.conf? So if you have lxc.system-cgroup-dir = /machine then root-created containers will end up in /machine (or, if you're already nested under /lxc/m1, then /lxc/m1/machine). If that is unset or /, then you're placed in root cgroup. If you're not root, then you end up under your current cgroup (assuming you have rights to create them, which you won't for some) Does that seem reasonable? 2. Any objections to implementing the mountcgroups hook in C? Especially if I want to do the cgroup mount point detection right (and not just assume /sys/fs/cgroup) it is going to be a huge pain to do that in shell, whereas in C I could reuse code. Nope - it'll require a hooks/Makefile.am tweak, is all. I was using scripts originally to encourage people to hack on them, but I'm not sure people are doing that anyway. (If we wanted to continue supporting that then we might want to use python) I think scripts are generally a good idea for this, but not in every use case, such as this one. And since the mountcgroups hook might be considered part of 'core' functionality, I also think Python is perhaps not the best choice, especially since LXC only supports Python 3.2+. -- Christian -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace
On 08/21/2013 06:42 PM, Eric W. Biederman wrote: Gao feng gaof...@cn.fujitsu.com writes: right now I only take note of the unix socket /run/systemd/private, but there may have many similar unix sockets, they can exist in any path. the strange problems will still happen. It could just as easily have been a fifo in the filesystem, and the result would have been the same. The network namespace are all about communicating between network namespaces and that is what was allowed here. If you don't want a socket or a fifo or any other file to be used by a container don't give it access to it. It really is that simple. Hmm, I tend to think you are right... Thanks! -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
