Re: [lxc-devel] regression: lxc-start -d hangs in lxc_monitor_sock_name (at process_lock)
On Thu, 12 Sep 2013 00:27:04 -0400 Stéphane Graber wrote: > Hello, > > It looks like Dwight's last change introduce a bit of a regression > when running lxc-start -d. Yikes, sorry I didn't catch that in my testing. My follow on patch for doing the monitor socket in the abstract space gets rid of this entirely, so this is an additional reason to consider it. > Tracing it down (added a ton of printf all over), it looks like it's > hanging on: > - lxcapi_start >- wait_on_daemonized_start > - lxcapi_wait >- lxc_wait > - lxc_monitor_open >- lxc_monitor_sock_name > > Specifically, it's hanging at the process_lock() call because > process_lock() was already called as part of lxcapi_start and only > gets unlocked right after wait_on_daemonized_start returns. > > > Looking at the code, I'm not even sure why we need process_lock there. > What it protects is another thread triggering the mkdir_p in parallel, > but that shouldn't really be a problem since running two mkdir_p at > the same time should still result in the hierarchy being created, or > did I miss something? That sounds logical to me, but hmm, does that mean we don't need it in lxclock_name() either (where I was modeling this on)? I wonder if there is a code flow that its possible for us to hang there. > Anyway, I'll let someone who knows that code better figure out a fix, > until then, lxc-start -d is broken in staging. > -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] hash lxcname for use in monitor unix socket sun_path[108]
Quoting Dwight Engen (dwight.en...@oracle.com):
> - Also convert to unix abstract socket
> - A simple FNV hash is used instead of SHA-1 since we may not HAVE_GNUTLS
>
> Signed-off-by: Dwight Engen
Acked-by: Serge E. Hallyn
Thanks Dwight! Works great.
> ---
> src/lxc/monitor.c | 60
> ---
> 1 file changed, 40 insertions(+), 20 deletions(-)
>
> diff --git a/src/lxc/monitor.c b/src/lxc/monitor.c
> index bdcc581..64e9987 100644
> --- a/src/lxc/monitor.c
> +++ b/src/lxc/monitor.c
> @@ -28,6 +28,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -123,38 +125,56 @@ int lxc_monitor_close(int fd)
> return close(fd);
> }
>
> +/* Note we don't use SHA-1 here as we don't want to depend on HAVE_GNUTLS.
> + * FNV has good anti collision properties and we're not worried
> + * about pre-image resistance or one-way-ness, we're just trying to make
> + * the name unique in the 108 bytes of space we have.
> + */
> +#define FNV1A_64_INIT ((uint64_t)0xcbf29ce484222325ULL)
> +static uint64_t fnv_64a_buf(void *buf, size_t len, uint64_t hval)
> +{
> + unsigned char *bp;
> +
> + for(bp = buf; bp < (unsigned char *)buf + len; bp++)
> + {
> + /* xor the bottom with the current octet */
> + hval ^= (uint64_t)*bp;
> +
> + /* gcc optimised:
> + * multiply by the 64 bit FNV magic prime mod 2^64
> + */
> + hval += (hval << 1) + (hval << 4) + (hval << 5) +
> + (hval << 7) + (hval << 8) + (hval << 40);
> + }
> +
> + return hval;
> +}
> +
> int lxc_monitor_sock_name(const char *lxcpath, struct sockaddr_un *addr) {
> size_t len;
> int ret;
> - char *sockname = &addr->sun_path[0]; // 1 for abstract
> - const char *rundir;
> + char *sockname = &addr->sun_path[1];
> + char path[PATH_MAX+18];
> + uint64_t hash;
>
> - /* addr.sun_path is only 108 bytes.
> - * should we take a hash of lxcpath? a subset of it? ftok()? we need
> - * to make sure it is unique.
> + /* addr.sun_path is only 108 bytes, so we hash the full name and
> + * then append as much of the name as we can fit.
>*/
> memset(addr, 0, sizeof(*addr));
> addr->sun_family = AF_UNIX;
> len = sizeof(addr->sun_path) - 1;
> - rundir = get_rundir();
> - ret = snprintf(sockname, len, "%s/lxc/%s", rundir, lxcpath);
> - if (ret < 0 || ret >= len) {
> - ERROR("rundir/lxcpath (%s/%s) too long for monitor unix
> socket", rundir, lxcpath);
> + ret = snprintf(path, sizeof(path), "lxc/%s/monitor-sock", lxcpath);
> + if (ret < 0 || ret >= sizeof(path)) {
> + ERROR("lxcpath %s too long for monitor unix socket", lxcpath);
> return -1;
> }
> - process_lock();
> - ret = mkdir_p(sockname, 0755);
> - process_unlock();
> - if (ret < 0) {
> - ERROR("unable to create monitor sock %s", sockname);
> - return ret;
> - }
>
> - ret = snprintf(sockname, len, "%s/lxc/%s/monitor-sock", rundir,
> lxcpath);
> - if (ret < 0 || ret >= len) {
> - ERROR("rundir/lxcpath (%s/%s) too long for monitor unix
> socket", rundir, lxcpath);
> + hash = fnv_64a_buf(path, ret, FNV1A_64_INIT);
> + ret = snprintf(sockname, len, "lxc/%016" PRIx64 "/%s", hash, lxcpath);
> + if (ret < 0)
> return -1;
> - }
> + sockname[sizeof(addr->sun_path)-2] = '\0';
> + INFO("using monitor sock name %s", sockname);
> return 0;
> }
>
> --
> 1.8.1.4
>
--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] regression: lxc-start -d hangs in lxc_monitor_sock_name (at process_lock)
Quoting Dwight Engen (dwight.en...@oracle.com): > On Thu, 12 Sep 2013 00:27:04 -0400 > Stéphane Graber wrote: > > > Hello, > > > > It looks like Dwight's last change introduce a bit of a regression > > when running lxc-start -d. > > Yikes, sorry I didn't catch that in my testing. My follow on patch > for doing the monitor socket in the abstract space gets rid of this > entirely, so this is an additional reason to consider it. > > > Tracing it down (added a ton of printf all over), it looks like it's > > hanging on: > > - lxcapi_start > >- wait_on_daemonized_start > > - lxcapi_wait > >- lxc_wait > > - lxc_monitor_open > >- lxc_monitor_sock_name > > > > Specifically, it's hanging at the process_lock() call because > > process_lock() was already called as part of lxcapi_start and only > > gets unlocked right after wait_on_daemonized_start returns. > > > > > > Looking at the code, I'm not even sure why we need process_lock there. > > What it protects is another thread triggering the mkdir_p in parallel, > > but that shouldn't really be a problem since running two mkdir_p at > > the same time should still result in the hierarchy being created, or > > did I miss something? > > That sounds logical to me, but hmm, does that mean we don't need it in > lxclock_name() either (where I was modeling this on)? I wonder if > there is a code flow that its possible for us to hang there. Well mkdir uses the umask right? (and *may* use the cwd). Both of which are shared among threads. It won't set them, but something else might change them underneath them. So I could be wrong and we might not need it, but it seemed like we might. -serge -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] cgroup: re-introduce ns cgroup support
Hi Serge, >> cgroups and have a separate function for the ns cgroup entries? Then > > Makes perfect sense to me to do so, yes. Since you didn't respond and I was in the mood to finish it, I assumed that you'd be OK with that, see my other set of patches for automatic cgroup mounting. -- Christian -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH] Update .gitignore
Signed-off-by: S.Çağlar Onur --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 8cecb72..660756f 100644 --- a/.gitignore +++ b/.gitignore @@ -59,6 +59,7 @@ src/lxc/lxc-netstat src/lxc/lxc-ps src/lxc/lxc-restart src/lxc/lxc-shutdown +src/lxc/lxc-snapshot src/lxc/lxc-start src/lxc/lxc-start-ephemeral src/lxc/lxc-stop -- 1.8.1.2 -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] cgroup: re-introduce ns cgroup support
Quoting Christian Seiler (christ...@iwakd.de): > Hi again, > > I was just looking at how to best implement the cgroup mount hook. > Problem now is that the easiest way would be just to create the cgroup > before the clone() (enter is done afterwards anyway) so that the client > has access to handler->pid. Unfortunately, handler->pid is needed for > the ns cgroup renaming scheme you just added. > > Is it OK if I split the function? I.e. have lxc_cgroup_create ignore ns I'm sorry, I thought I had replied to this last night. I'm certain I wrote a response, dunno what happened to it... > cgroups and have a separate function for the ns cgroup entries? Then Makes perfect sense to me to do so, yes. > lxc_cgroup_create could be called before the clone and the ns handling > function afterwards. And the cgroup mounting hook would mount only the > root cgroup for ns cgroups anyway. (Or ignore them.) > Btw., OT: I'm having trouble with lxc-start -d in the current staging; > the container starts find in the background, but lxc-start doesn't > terminate. If I kill it with Ctrl+C, the container continues running > (because it's already forked away) but the foreground lxc-start seems to > hang completely... lxc-start without -d behaves normally. Yeah, I just pushed Dwight's commit which should fix that - thanks. -serge -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [RFC] rootfs pinning
Hi there, just a quick question: currently, rootfs is pinned with a .hold file in the parent directory (which btw. does not help against file systems that are already mounted on the host but directly in the rootfs directory). The problem with the .hold file is that it doesn't make the directory necessarily pretty; I tend to mount all rootfs to /srv/lxc/$container (config remaining in /var/lib/lxc), and then when doing a ls /srv/lxc, I see tons of .hold files. (I'm not even sure that they are removed after container termination - but even if they are, the default state of a typical system tends to be that at least some containers are running...) Couldn't we just open $rootfs/lxc.hold for writing, keep the fd (as current pinfd) and then unlink (!) the file directly? According to POSIX semantics, the file is then still open and the pinning should work (now also for the above case), but there are no files lying around anymore. (Note: I didn't test that, it could well be that that doesn't work.) Thoughts? -- Christian -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [RFC] rootfs pinning
Quoting Christian Seiler (christ...@iwakd.de): > Hi there, > > just a quick question: currently, rootfs is pinned with a .hold file in > the parent directory (which btw. does not help against file systems that > are already mounted on the host but directly in the rootfs directory). > The problem with the .hold file is that it doesn't make the directory > necessarily pretty; I tend to mount all rootfs to /srv/lxc/$container > (config remaining in /var/lib/lxc), and then when doing a ls /srv/lxc, I > see tons of .hold files. (I'm not even sure that they are removed after > container termination - but even if they are, the default state of a No I don't think they are removed at all. > typical system tends to be that at least some containers are running...) > > Couldn't we just open $rootfs/lxc.hold for writing, keep the fd (as > current pinfd) and then unlink (!) the file directly? According to POSIX Yup, we could do that, absolutely no problem with that. I just didn't do it. It would work, and keep the directory neat, so +1. > semantics, the file is then still open and the pinning should work (now > also for the above case), but there are no files lying around anymore. > (Note: I didn't test that, it could well be that that doesn't work.) > > Thoughts? > > -- Christian > > -- > How ServiceNow helps IT people transform IT departments: > 1. Consolidate legacy IT systems to a single system of record for IT > 2. Standardize and globalize service processes across IT > 3. Implement zero-touch automation to replace manual, redundant tasks > http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk > ___ > Lxc-devel mailing list > Lxc-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-devel -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [RFC] rootfs pinning
On Thu, Sep 12, 2013 at 08:27:07PM +0200, Christian Seiler wrote:
> Hi there,
>
> just a quick question: currently, rootfs is pinned with a .hold file in
> the parent directory (which btw. does not help against file systems that
> are already mounted on the host but directly in the rootfs directory).
> The problem with the .hold file is that it doesn't make the directory
> necessarily pretty; I tend to mount all rootfs to /srv/lxc/$container
> (config remaining in /var/lib/lxc), and then when doing a ls /srv/lxc, I
> see tons of .hold files. (I'm not even sure that they are removed after
> container termination - but even if they are, the default state of a
> typical system tends to be that at least some containers are running...)
>
> Couldn't we just open $rootfs/lxc.hold for writing, keep the fd (as
> current pinfd) and then unlink (!) the file directly? According to POSIX
> semantics, the file is then still open and the pinning should work (now
> also for the above case), but there are no files lying around anymore.
> (Note: I didn't test that, it could well be that that doesn't work.)
>
> Thoughts?
Removing the file without closing the fd should work fine, just to
confirm, I did:
root@castiana:~# mount -t tmpfs tmpfs /mnt
root@castiana:~# python3
Python 3.3.2+ (default, Jun 5 2013, 10:51:51)
[GCC 4.8.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> fd = open("/mnt/a", "w+")
>>> os.remove("/mnt/a")
>>>
[1]+ Stopped python3
root@castiana:~# mount -o remount,ro /mnt
mount: /mnt is busy
root@castiana:~# lsof -n | grep /mnt/a
python39300 root3u REG 0,46
0 289559 /mnt/a (deleted)
root@castiana:~# fg
python3
>>>
root@castiana:~# mount -o remount,ro /mnt
root@castiana:~# umount /mnt
root@castiana:~#
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
signature.asc
Description: Digital signature
--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 2/4] cgroup: Split legacy 'ns' cgroup handling off from main cgroup handling
Quoting Christian Seiler (christ...@iwakd.de):
> This patch splits off ns legacy cgroup handling from main cgroup
> handling. It moves the creation of the cgroups before clone(), so that
> the child will easily know which cgroups it will later belong to. Since
> this is not possible for the renaming of the 'ns' cgroup, keep that
> part after clone.
>
> Signed-off-by: Christian Seiler
Acked-by: Serge E. Hallyn
> ---
> src/lxc/cgroup.c | 61
> +++---
> src/lxc/cgroup.h |3 ++-
> src/lxc/start.c | 15 --
> 3 files changed, 55 insertions(+), 24 deletions(-)
>
> diff --git a/src/lxc/cgroup.c b/src/lxc/cgroup.c
> index aaee546..ad95fc4 100644
> --- a/src/lxc/cgroup.c
> +++ b/src/lxc/cgroup.c
> @@ -604,7 +604,7 @@ static char *cgroup_rename_nsgroup(const char *mountpath,
> const char *oldname, p
> }
>
> /* create a new cgroup */
> -extern struct cgroup_process_info *lxc_cgroup_create(const char *name, const
> char *path_pattern, struct cgroup_meta_data *meta_data, const char
> *sub_pattern, pid_t pid)
> +extern struct cgroup_process_info *lxc_cgroup_create(const char *name, const
> char *path_pattern, struct cgroup_meta_data *meta_data, const char
> *sub_pattern)
> {
> char **cgroup_path_components = NULL;
> char **p = NULL;
> @@ -826,27 +826,16 @@ extern struct cgroup_process_info
> *lxc_cgroup_create(const char *name, const cha
>
> /* we're done, now update the paths */
> for (i = 0, info_ptr = base_info; info_ptr; info_ptr = info_ptr->next,
> i++) {
> - /*
> - * For any path which has ns cgroup mounted, handler->pid is
> already
> - * moved into a container called '%d % (handler->pid)'. Rename
> it to
> - * the cgroup name and record that.
> + /* ignore legacy 'ns' subsystem here, lxc_cgroup_create_legacy
> + * will take care of it
> + * Since we do a continue in above loop, new_cgroup_paths[i] is
> + * unset anyway, as is new_cgroup_paths_sub[i]
>*/
> - if (lxc_string_in_array("ns", (const char
> **)info_ptr->hierarchy->subsystems)) {
> - char *tmp = cgroup_rename_nsgroup((const char
> *)info_ptr->designated_mount_point->mount_point,
> - info_ptr->cgroup_path, pid, name);
> - if (!tmp)
> - goto out_initial_error;
> - free(info_ptr->cgroup_path);
> - info_ptr->cgroup_path = tmp;
> - r = lxc_grow_array((void ***)&info_ptr->created_paths,
> &info_ptr->created_paths_capacity, info_ptr->created_paths_count + 1, 8);
> - if (r < 0)
> - goto out_initial_error;
> -
> info_ptr->created_paths[info_ptr->created_paths_count++] = strdup(tmp);
> - } else {
> - free(info_ptr->cgroup_path);
> - info_ptr->cgroup_path = new_cgroup_paths[i];
> - info_ptr->cgroup_path_sub = new_cgroup_paths_sub[i];
> - }
> + if (lxc_string_in_array("ns", (const char
> **)info_ptr->hierarchy->subsystems))
> + continue;
> + free(info_ptr->cgroup_path);
> + info_ptr->cgroup_path = new_cgroup_paths[i];
> + info_ptr->cgroup_path_sub = new_cgroup_paths_sub[i];
> }
> /* don't use lxc_free_array since we used the array members
>* to store them in our result...
> @@ -868,6 +857,36 @@ out_initial_error:
> return NULL;
> }
>
> +int lxc_cgroup_create_legacy(struct cgroup_process_info *base_info, const
> char *name, pid_t pid)
> +{
> + struct cgroup_process_info *info_ptr;
> + int r;
> +
> + for (info_ptr = base_info; info_ptr; info_ptr = info_ptr->next) {
> + if (!lxc_string_in_array("ns", (const char
> **)info_ptr->hierarchy->subsystems))
> + continue;
> + /*
> + * For any path which has ns cgroup mounted, handler->pid is
> already
> + * moved into a container called '%d % (handler->pid)'. Rename
> it to
> + * the cgroup name and record that.
> + */
> + char *tmp = cgroup_rename_nsgroup((const char
> *)info_ptr->designated_mount_point->mount_point,
> + info_ptr->cgroup_path, pid, name);
> + if (!tmp)
> + return -1;
> + free(info_ptr->cgroup_path);
> + info_ptr->cgroup_path = tmp;
> + r = lxc_grow_array((void ***)&info_ptr->created_paths,
> &info_ptr->created_paths_capacity, info_ptr->created_paths_count + 1, 8);
> + if (r < 0)
> + return -1;
> + tmp = strdup(tmp);
> + if (!tmp)
> + return -1;
> + in
Re: [lxc-devel] [PATCH 3/4] cgroup: Add lxc_setup_mount_cgroup to setup /sys/fs/cgroup inside the container
Quoting Christian Seiler (christ...@iwakd.de): > Add funbction to mount cgroup filesystem hierarchy into the container, > allowing only access to the parts that the container should have access > to, but none else. > > Signed-off-by: Christian Seiler Hm, these last two patches aren't working for me. They don't break anything in a normal setup, but when I try use lxc.mount.auto it hangs. It may not be a fault in the patches, as mountall starts and hangs. -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 4bee03: Update .gitignore
Branch: refs/heads/staging Home: https://github.com/lxc/lxc Commit: 4bee03bc9df2c2437f068f284327aff337cbdaa9 https://github.com/lxc/lxc/commit/4bee03bc9df2c2437f068f284327aff337cbdaa9 Author: S.Çağlar Onur Date: 2013-09-12 (Thu, 12 Sep 2013) Changed paths: M .gitignore Log Message: --- Update .gitignore Signed-off-by: S.Çağlar Onur Signed-off-by: Serge Hallyn Commit: 24b514827d8fb6a11521da3f29b80b25c488e8c6 https://github.com/lxc/lxc/commit/24b514827d8fb6a11521da3f29b80b25c488e8c6 Author: Christian Seiler Date: 2013-09-12 (Thu, 12 Sep 2013) Changed paths: M src/lxc/utils.c M src/lxc/utils.h Log Message: --- utils: Add lxc_append_paths to join two paths. Signed-off-by: Christian Seiler Signed-off-by: Serge Hallyn Commit: 47d8fb3be090fc99118bb7fea8cb12b3e2194999 https://github.com/lxc/lxc/commit/47d8fb3be090fc99118bb7fea8cb12b3e2194999 Author: Christian Seiler Date: 2013-09-12 (Thu, 12 Sep 2013) Changed paths: M src/lxc/cgroup.c M src/lxc/cgroup.h M src/lxc/start.c Log Message: --- cgroup: Split legacy 'ns' cgroup handling off from main cgroup handling This patch splits off ns legacy cgroup handling from main cgroup handling. It moves the creation of the cgroups before clone(), so that the child will easily know which cgroups it will later belong to. Since this is not possible for the renaming of the 'ns' cgroup, keep that part after clone. Signed-off-by: Christian Seiler Signed-off-by: Serge Hallyn Commit: aae1f3c47b09dfcecd17ec56a5fccfc60e52a220 https://github.com/lxc/lxc/commit/aae1f3c47b09dfcecd17ec56a5fccfc60e52a220 Author: Christian Seiler Date: 2013-09-12 (Thu, 12 Sep 2013) Changed paths: M src/lxc/cgroup.c M src/lxc/cgroup.h Log Message: --- cgroup: Add lxc_setup_mount_cgroup to setup /sys/fs/cgroup inside the container Add funbction to mount cgroup filesystem hierarchy into the container, allowing only access to the parts that the container should have access to, but none else. Signed-off-by: Christian Seiler Signed-off-by: Serge Hallyn Compare: https://github.com/lxc/lxc/compare/b336d7246a32...aae1f3c47b09 -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 3/4] cgroup: Add lxc_setup_mount_cgroup to setup /sys/fs/cgroup inside the container
Hi Serge, >> I could get behind the following: >> >>proc- always read-write (no harm AFAICT) >>sys - default: read-only >>sys:rw - read-write >>sys:ro - explicit read-only >>cgroup:ro - completely ro (including paths) >>cgroup:rw - completely rw (including paths) > > That sounds good. > >>cgroup:mixed- paths ro, other rw > > what is 'paths' vs. 'other' here? There's > > /sys/fs/cgroup > > itself, > > /sys/fs/cgroup/$subsys > > then the paths up to the container's own path, and then > there's the stuff under the container's own path. I'm not > clear on which you're calling what. What I meant is that mixed is the current staging behaviour, i.e. - /sys/fs/cgroup: tmpfs, ro after setup - /sys/fs/cgroup/$subsys/$container_cgroup: bind-mount, rw So that /sys/fs/cgroup is r/o, /sys/fs/cgroup/$subsys is r/o, /sys/fs/cgroup/$subsys/$parent_of_container_cgroup is r/o but /sys/fs/cgroup/$subsys/$container_cgroup is r/w. >>cgroup-full:ro- mount complete tree read-only (not just partial) >>cgroup-full:rw- mount complete tree read-write (not just partial) >>cgroup-full:mixed - mount complete tree read-only but bind-mount >>partial tree read-write >>cgroup-full - defaults to cgroup-full: mixed > > Hm, but you're doing the full tree by default. What is the difference > between this and cgroup:ro? cgroup-full:mixed would be: - /sys/fs/cgroup: tmpfs, ro - /sys/fs/cgroup/$subsys bind-mount, ro - /sys/fs/cgroup/$subsys/$container_cgroup bind-mount, rw That has the advantage that /sys/fs/cgroup/$subsys is actually a cgroup filesystem (even though it's read-only), which may improve compatibility compared to the current behavior, but the disadvantage that the names of all cgroups of the host (including those in other containers) leak into the container (even though the container can't really do anything with them, if it doesn't have mount permissions). cgroup-full:rw would just mount everything into /sys/fs/cgroup as it should be according to the standard and make everything read-write. cgroup-full:ro would do the same as cgroup-full:rw but read-only. It then depends on the policy of the administrator and the compatibility level of software that is to be run in the container what option should be chosen. Would you agree? -- Christian -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] Change rootfs pinning mechnism
Quoting Christian Seiler (christ...@iwakd.de):
> Chane pinning mechanism: Use $rootfs/lxc.hold instead of $rootfs.hold
> (in case $rootfs is a mountpoint itself), but delete the file
> immediately after creating it (but keep it open). This will keep the
> root filesystem busy but does not leave any unnecessary files lying
> around.
>
> Signed-off-by: Christian Seiler
Acked-by: Serge E. Hallyn
> ---
> src/lxc/conf.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/src/lxc/conf.c b/src/lxc/conf.c
> index 5f9ae87..291ea6f 100644
> --- a/src/lxc/conf.c
> +++ b/src/lxc/conf.c
> @@ -670,9 +670,10 @@ static int mount_rootfs_block(const char *rootfs, const
> char *target)
>
> /*
> * pin_rootfs
> - * if rootfs is a directory, then open ${rootfs}.hold for writing for the
> - * duration of the container run, to prevent the container from marking the
> - * underlying fs readonly on shutdown.
> + * if rootfs is a directory, then open ${rootfs}/lxc.hold for writing for
> + * the duration of the container run, to prevent the container from marking
> + * the underlying fs readonly on shutdown. unlink the file immediately so
> + * no name pollution is happens
> * return -1 on error.
> * return -2 if nothing needed to be pinned.
> * return an open fd (>=0) if we pinned it.
> @@ -699,11 +700,14 @@ int pin_rootfs(const char *rootfs)
> if (!S_ISDIR(s.st_mode))
> return -2;
>
> - ret = snprintf(absrootfspin, MAXPATHLEN, "%s%s", absrootfs, ".hold");
> + ret = snprintf(absrootfspin, MAXPATHLEN, "%s/lxc.hold", absrootfs);
> if (ret >= MAXPATHLEN)
> return -1;
>
> fd = open(absrootfspin, O_CREAT | O_RDWR, S_IWUSR|S_IRUSR);
> + if (fd < 0)
> + return fd;
> + (void)unlink(absrootfspin);
> return fd;
> }
>
> --
> 1.7.10.4
>
--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 368bbc: Support for automatic mounting of filesystems
Branch: refs/heads/staging Home: https://github.com/lxc/lxc Commit: 368bbc02ba132cd978141f392e610adf3b9dcec8 https://github.com/lxc/lxc/commit/368bbc02ba132cd978141f392e610adf3b9dcec8 Author: Christian Seiler Date: 2013-09-12 (Thu, 12 Sep 2013) Changed paths: M src/lxc/conf.c M src/lxc/conf.h M src/lxc/confile.c M src/lxc/start.c Log Message: --- Support for automatic mounting of filesystems This patch adds the lxc.mount.auto configuration option that allows the user to specify that certain standard filesystems should be automatically pre-mounted when the container is started. Currently, four things are implemented: - /proc (mounted read-write) - /sys (mounted read-only) - /sys/fs/cgroup (special logic, see mailing list discussions) - /proc/sysrq-trigger (see below) /proc/sysrq-trigger may be used from within a container to trigger a forced host reboot (echo b > /proc/sysrq-trigger) or do other things that a container shouldn't be able to do. The logic here is to bind-mount /dev/null over /proc/sysrq-trigger, so that that cannot happen. This obviously only protects fully if CAP_SYS_ADMIN is not available inside the container (otherwise that bind-mount could be removed). Signed-off-by: Christian Seiler Signed-off-by: Serge Hallyn Commit: b7ed4bf0e25799fbe9e9ccb073af5397dda1288a https://github.com/lxc/lxc/commit/b7ed4bf0e25799fbe9e9ccb073af5397dda1288a Author: Christian Seiler Date: 2013-09-12 (Thu, 12 Sep 2013) Changed paths: M src/lxc/conf.c Log Message: --- Change rootfs pinning mechnism Chane pinning mechanism: Use $rootfs/lxc.hold instead of $rootfs.hold (in case $rootfs is a mountpoint itself), but delete the file immediately after creating it (but keep it open). This will keep the root filesystem busy but does not leave any unnecessary files lying around. Signed-off-by: Christian Seiler Signed-off-by: Serge Hallyn Compare: https://github.com/lxc/lxc/compare/aae1f3c47b09...b7ed4bf0e257 -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/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/1] snapshots: add man page and fix up help info a bit.
On Thu, Sep 12, 2013 at 03:08:26PM -0500, Serge Hallyn wrote:
Awesome, I noticed it was missing when going through lintian output this
morning and added it to my TODO for later this cycle, glad I won't have
to do it myself then :)
Acked-by: Stéphane Graber
> Signed-off-by: Serge Hallyn
> ---
> configure.ac | 1 +
> doc/Makefile.am | 1 +
> doc/lxc-snapshot.sgml.in | 152
> +++
> src/lxc/lxc_snapshot.c | 7 ++-
> 4 files changed, 158 insertions(+), 3 deletions(-)
> create mode 100644 doc/lxc-snapshot.sgml.in
>
> diff --git a/configure.ac b/configure.ac
> index c734bea..6c74dcd 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -414,6 +414,7 @@ AC_CONFIG_FILES([
> doc/lxc-netstat.sgml
> doc/lxc-ps.sgml
> doc/lxc-restart.sgml
> + doc/lxc-snapshot.sgml
> doc/lxc-start-ephemeral.sgml
> doc/lxc-start.sgml
> doc/lxc-stop.sgml
> diff --git a/doc/Makefile.am b/doc/Makefile.am
> index 2321a68..f2a106b 100644
> --- a/doc/Makefile.am
> +++ b/doc/Makefile.am
> @@ -22,6 +22,7 @@ man_MANS = \
> lxc-netstat.1 \
> lxc-ps.1 \
> lxc-restart.1 \
> + lxc-snapshot.1 \
> lxc-start.1 \
> lxc-stop.1 \
> lxc-unfreeze.1 \
> diff --git a/doc/lxc-snapshot.sgml.in b/doc/lxc-snapshot.sgml.in
> new file mode 100644
> index 000..f66070b
> --- /dev/null
> +++ b/doc/lxc-snapshot.sgml.in
> @@ -0,0 +1,152 @@
> +
> +
> + +
> +
> +
> +]>
> +
> +
> +
> + @LXC_GENERATE_DATE@
> +
> +
> +lxc-snapshot
> +1
> +
> +
> +
> +lxc-snapshot
> +
> +
> + Snapshot an existing container.
> +
> +
> +
> +
> +
> + lxc-snapshot
> + -n, --name name
> + -c, --comment file
> +
> +
> + lxc-snapshot
> + -n, --name name
> + -L, --list
> + -C, --showcomments
> +
> +
> + lxc-snapshot
> + -n, --name name
> + -r, -restore
> snapshot-name
> +newname
> +
> +
> +
> +
> +Description
> +
> +
> + lxc-snapshot creates, lists, and restores
> + container snapshots.
> +
> +
> +Snapshots are stored as snapshotted containers under a private
> configuration path. For instance, if the container's configuration path is
> /var/lib/lxc and the container is
> c1, then the first snapshot will be stored as container
> snap0 under configuration path
> /var/lib/lxcsnaps/c1.
> +
> +
> +
> +
> +
> +Options
> +
> +
> +
> +
> + -c,--comment
> comment_file
> +
> + Associate the comment in
> comment_file with the newly created
> snapshot.
> +
> +
> +
> +
> + -L,--list
> +
> + List existing snapshots.
> +
> +
> +
> +
> + -C,--showcomments
> +
> + Show snapshot comments in the snapshots listings.
> +
> +
> +
> +
> + -r,--restore snapshot-name
> +
> + Restore the named snapshot, meaning a full new container is
> created which is a copy of the snapshot.
> +
> +
> +
> +
> + newname
> +
> + When restoring a snapshot, the last optional argument is the
> name to use for the restored container. If no name is given, then the
> original container will be destroyed and the restored container will take its
> place. Note that deleting the original snapshot is not possible in the case
> of overlayfs or zfs backed snapshots.
> +
> +
> +
> +
> +
> +
> +
> + &commonoptions;
> +
> + &seealso;
> +
> +
> +Author
> +Serge Hallyn serge.hal...@ubuntu.com
> +
> +
> +
> +
> +
> diff --git a/src/lxc/lxc_snapshot.c b/src/lxc/lxc_snapshot.c
> index 05562f0..0177f5d 100644
> --- a/src/lxc/lxc_snapshot.c
> +++ b/src/lxc/lxc_snapshot.c
> @@ -129,13 +129,14 @@ static const struct option my_longopts[] = {
>
>
> static struct lxc_arguments my_args = {
> - .progname = "lxc-create",
> + .progname = "lxc-snapshot",
> .help = "\
> ---name=NAME [-w] [-r] [-t timeout] [-P lxcpath]\n\
> +--name=NAME [-P lxcpath] [-L [-C]] [-c commentfile] [-r snapname
> [newname]]\n\
> \n\
> -lxc-create creates a container\n\
> +lxc-snapshot snapshots a container\n\
> \n\
> Options :\n\
> + -n, --name=NAME NAME for name of the container\n\
>-L, --list list snapshots\n\
>-C, --showcomments show snapshot comments in list\n\
>-c, --comment=file add file as a comment\n\
> --
> 1.8.1.2
>
>
> --
> How ServiceNow helps IT people transform IT departments:
> 1. Consolidate legacy IT systems to a single system of record for IT
> 2. Standardize and globalize service processes across IT
> 3. Implement zero-touch automation to replace manual, redundant tasks
> http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.
Re: [lxc-devel] [PATCH] Update .gitignore
Quoting S.Çağlar Onur (cag...@10ur.org): > Signed-off-by: S.Çağlar Onur Acked-by: Serge E. Hallyn applying, thanks. > --- > .gitignore | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/.gitignore b/.gitignore > index 8cecb72..660756f 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -59,6 +59,7 @@ src/lxc/lxc-netstat > src/lxc/lxc-ps > src/lxc/lxc-restart > src/lxc/lxc-shutdown > +src/lxc/lxc-snapshot > src/lxc/lxc-start > src/lxc/lxc-start-ephemeral > src/lxc/lxc-stop > -- > 1.8.1.2 > > > -- > How ServiceNow helps IT people transform IT departments: > 1. Consolidate legacy IT systems to a single system of record for IT > 2. Standardize and globalize service processes across IT > 3. Implement zero-touch automation to replace manual, redundant tasks > http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk > ___ > Lxc-devel mailing list > Lxc-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-devel -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] regression: lxc-start -d hangs in lxc_monitor_sock_name (at process_lock)
Hi, I think staging (my head is @ 813a48...) started to stuck while creating containers concurrently after monitoring related changes. I observed that issue with the Go bindings first. Then I wrote a test case to remove Go from the picture and I also thought that having a test case would be helpful (see "[PATCH] tests: Introduce lxc-test-concurrent for testing basic actions concurrently"). Normally one should see following [caglar@qgq:~/Projects/lxc(staging)] sudo lxc-test-concurrent Executing (create) for 5 containers... Executing (start) for 5 containers... Executing (stop) for 5 containers... Executing (destroy) for 5 containers... but occasionally create started to stuck on my test system (just try to run couple of times). Cheers, On Thu, Sep 12, 2013 at 10:41 AM, Serge Hallyn wrote: > Quoting Dwight Engen (dwight.en...@oracle.com): > > On Thu, 12 Sep 2013 00:27:04 -0400 > > Stéphane Graber wrote: > > > > > Hello, > > > > > > It looks like Dwight's last change introduce a bit of a regression > > > when running lxc-start -d. > > > > Yikes, sorry I didn't catch that in my testing. My follow on patch > > for doing the monitor socket in the abstract space gets rid of this > > entirely, so this is an additional reason to consider it. > > > > > Tracing it down (added a ton of printf all over), it looks like it's > > > hanging on: > > > - lxcapi_start > > >- wait_on_daemonized_start > > > - lxcapi_wait > > >- lxc_wait > > > - lxc_monitor_open > > >- lxc_monitor_sock_name > > > > > > Specifically, it's hanging at the process_lock() call because > > > process_lock() was already called as part of lxcapi_start and only > > > gets unlocked right after wait_on_daemonized_start returns. > > > > > > > > > Looking at the code, I'm not even sure why we need process_lock there. > > > What it protects is another thread triggering the mkdir_p in parallel, > > > but that shouldn't really be a problem since running two mkdir_p at > > > the same time should still result in the hierarchy being created, or > > > did I miss something? > > > > That sounds logical to me, but hmm, does that mean we don't need it in > > lxclock_name() either (where I was modeling this on)? I wonder if > > there is a code flow that its possible for us to hang there. > > Well mkdir uses the umask right? (and *may* use the cwd). Both of > which are shared among threads. It won't set them, but something else > might change them underneath them. > > So I could be wrong and we might not need it, but it seemed like we > might. > > -serge > > > -- > How ServiceNow helps IT people transform IT departments: > 1. Consolidate legacy IT systems to a single system of record for IT > 2. Standardize and globalize service processes across IT > 3. Implement zero-touch automation to replace manual, redundant tasks > http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk > ___ > Lxc-devel mailing list > Lxc-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-devel > -- S.Çağlar Onur -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [Lxc-users] Working LXC templates? EUREAKA! I think I've got it!
All - Especially Tony Su,
Couple of people where I work thought you couldn't do what I was trying
to do, that it was "impossible". Oh well. Looks like they were
wrong. :-P It may not be "efficient" but it can be made to work.
Way down below, in-line...
On Mon, 2013-09-09 at 07:28 -0400, Michael H. Warfield wrote:
> On Mon, 2013-09-09 at 08:58 +0200, Natanael Copa wrote:
> > On Sun, 08 Sep 2013 20:33:16 -0400
> > "Michael H. Warfield" wrote:
> >
> > > With all due respect...
> > >
> > > On Sun, 2013-09-08 at 16:08 -0700, Tony Su wrote:
> > > > After putting some thought into this,
> > > > IMO LXC badly needs a universal tool with the following features
> > > >
> > > > - A single script should be used to run on HostOS, creating
> > > > supported Container OS. Although this would make the script
> > > > extremely large, IMO it would actually be easier to maintain in the
> > > > long run.
> > >
> > > Actually, no. From my experience (30+ years in software development),
> > > it would turn into a morass.
> > >
> > > The problem here is that the maintainer(s) would then need to understand
> > > how each and every distribution is installed and how it would be
> > > installed on each and every distribution. It would distill the worse of
> > > all the problems we have now in the templates into one great big dung
> > > pile. It would rapidly become unmaintainable. The "extremely large" is
> > > the red letter warning that it will become unmaintainable as fewer and
> > > fewer people understand what this great big huge blob does.
>
> > I tend to agree with this.
> > What I do think could be done is to use template APIs. Either by having
> > a script "library" with helper functions (for things like:
> > generate_mac_address etc) or let the template scripts be "plugins" that
> > must provide a set of pre-defined functions (eg. install_distro,
> > configure_distro, copy_configuration etc) or maybe a combination of
> > those two.
> I like this idea, it's just that, in the short term, we have to get past
> this one gotcha.
> In the git-stage current Fedora template, the entire problem is embodied
> in the "download_fedora" function starting around line 201... The
> gotcha's are three commands around line 272 after we've identified and
> downloaded the initial release rpm. We have this:
>
> mkdir -p $INSTALL_ROOT/var/lib/rpm
> rpm --root $INSTALL_ROOT --initdb
> rpm --root $INSTALL_ROOT -ivh ${INSTALL_ROOT}/${RELEASE_RPM}
> $YUM install $PKG_LIST
> Ok... Those are running in the host local run time environment.
> Obviously, if the host does not have a (compatible) version of rpm
> and/or yum in the host local environment, you're screwed. That's the
> catch-22 situation and it's the same situation with zypper in the
> OpenSuse template. That short space of code has to be recreated in a
> totally distro-agnostic manner so it runs on any distro to create our
> initial rootfs. After that, we can do what ever distro (Fedora)
> specific commands we want by chrooting into the target container first
> (including rebuilding the rpm database to the target version). That's
> only even needed if you don't already have a cached rootfs for that
> distro and version.
> I was S close last week working on this while on vacation. Recent
> revs of Fedora have this downloadable LiveOS core that runs on the
> netinst CD and others. That's the 200MB - 300MB blob I was referring
> to. You just download it, mount it (requires squashfs) to a directory
> and then mount the ext3 image it contains on another directory. Then
> create and bind mount a few rw directories (etc var run), mount proc in
> the image, and bind mount your rootfs to run/install in the image. Then
> chroot into the image and voila, instant RTE. Yum and rpm are capable
> of installing other versions of Fedora, so I wouldn't (shouldn't) even
> need a version specific instantiation of the RTE, just one that can
> install every version we might be interested in.
> Except... It didn't work. Sigh... $#@$#@#@
> Fedora came so close and then face planted for what I wanted to do.
> Sure rpm is in there. But rpmdb is not. So, no --initdb and no
> --rebuilddb. They've got yum in there, but no yummain.py so yum hurls
> chunks immediately upon execution trying to import yummain. What the
> hell good does it do to have yum in there but no yummain?!?! But,
> something, fixed up, like that from all the distros would be a perfect
> answer (albeit somewhat less than high performance thanks to that
> download, but it's a single download that could be cached). The only
> potential gotcha I see in there is requiring squashfs available for
> mounting the image. Anyone have heartburn over that?
> That squashfs image has to be able to do an install or it would be
> useless on the netinst CD. I'm not sure if they still have anaconda on
> there or not but it has to be able to do a kickstart install, so all I
> need is a minimal.
[lxc-devel] [lxc/lxc] b336d7: ignore ability to init /lxc-monitord.log
Branch: refs/heads/staging Home: https://github.com/lxc/lxc Commit: b336d7246a324e8973bc449cb35db40b1627be47 https://github.com/lxc/lxc/commit/b336d7246a324e8973bc449cb35db40b1627be47 Author: Serge Hallyn Date: 2013-09-12 (Thu, 12 Sep 2013) Changed paths: M src/lxc/lxc_monitord.c Log Message: --- ignore ability to init /lxc-monitord.log We may long-term want to instead decide on a convention under /var/log, but for now just ignore it. This will only happen if lxcpath is read-only. Signed-off-by: Serge Hallyn -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 3/4] cgroup: Add lxc_setup_mount_cgroup to setup /sys/fs/cgroup inside the container
Quoting Christian Seiler (christ...@iwakd.de):
> Add funbction to mount cgroup filesystem hierarchy into the container,
> allowing only access to the parts that the container should have access
> to, but none else.
>
> Signed-off-by: Christian Seiler
Acked-by: Serge E. Hallyn
This looks good to me. As I say it's not working for me, but the patch
itself looks fine.
> ---
> src/lxc/cgroup.c | 127
> ++
> src/lxc/cgroup.h |2 +
> 2 files changed, 129 insertions(+)
>
> diff --git a/src/lxc/cgroup.c b/src/lxc/cgroup.c
> index ad95fc4..876c60c 100644
> --- a/src/lxc/cgroup.c
> +++ b/src/lxc/cgroup.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -1200,6 +1201,132 @@ int lxc_setup_cgroup_devices(struct lxc_handler *h,
> struct lxc_list *cgroup_sett
> return do_setup_cgroup(h, cgroup_settings, true);
> }
>
> +int lxc_setup_mount_cgroup(const char *root, struct cgroup_process_info
> *base_info)
> +{
> + size_t bufsz = strlen(root) + sizeof("/sys/fs/cgroup");
> + char *path = NULL;
> + char **parts = NULL;
> + char *dirname = NULL;
> + char *abs_path = NULL;
> + char *abs_path2 = NULL;
> + struct cgroup_process_info *info;
> + int r, saved_errno = 0;
> +
> + path = calloc(1, bufsz);
> + if (!path)
> + return -1;
> + snprintf(path, bufsz, "%s/sys/fs/cgroup", root);
> + r = mount("cgroup_root", path, "tmpfs",
> MS_NOSUID|MS_NODEV|MS_NOEXEC|MS_RELATIME, "size=10240k,mode=755");
> + if (r < 0) {
> + SYSERROR("could not mount tmpfs to /sys/fs/cgroup in the
> container");
> + return -1;
> + }
> +
> + /* now mount all the hierarchies we care about */
> + for (info = base_info; info; info = info->next) {
> + size_t subsystem_count, i;
> + struct cgroup_mount_point *mp = info->designated_mount_point;
> + if (!mp)
> + mp = lxc_cgroup_find_mount_point(info->hierarchy,
> info->cgroup_path, true);
> + if (!mp) {
> + SYSERROR("could not find original mount point for
> cgroup hierarchy while trying to mount cgroup filesystem");
> + goto out_error;
> + }
> +
> + subsystem_count = lxc_array_len((void
> **)info->hierarchy->subsystems);
> + parts = calloc(subsystem_count + 1, sizeof(char *));
> + if (!parts)
> + goto out_error;
> +
> + for (i = 0; i < subsystem_count; i++) {
> + if (!strncmp(info->hierarchy->subsystems[i], "name=",
> 5))
> + parts[i] = info->hierarchy->subsystems[i] + 5;
> + else
> + parts[i] = info->hierarchy->subsystems[i];
> + }
> + dirname = lxc_string_join(",", (const char **)parts, false);
> + if (!dirname)
> + goto out_error;
> +
> + /* create subsystem directory */
> + abs_path = lxc_append_paths(path, dirname);
> + if (!abs_path)
> + goto out_error;
> + r = mkdir_p(abs_path, 0755);
> + if (r < 0 && errno != EEXIST) {
> + SYSERROR("could not create cgroup subsystem directory
> /sys/fs/cgroup/%s", dirname);
> + goto out_error;
> + }
> +
> + /* create path for container's cgroup */
> + abs_path2 = lxc_append_paths(abs_path, info->cgroup_path);
> + if (!abs_path2)
> + goto out_error;
> + r = mkdir_p(abs_path2, 0755);
> + if (r < 0 && errno != EEXIST) {
> + SYSERROR("could not create cgroup directory
> /sys/fs/cgroup/%s%s", dirname, info->cgroup_path);
> + goto out_error;
> + }
> +
> + free(abs_path);
> + abs_path = NULL;
> +
> + /* bind-mount container's cgroup to that directory */
> + abs_path = cgroup_to_absolute_path(mp, info->cgroup_path, NULL);
> + if (!abs_path)
> + goto out_error;
> + r = mount(abs_path, abs_path2, "none", MS_BIND, 0);
> + if (r < 0) {
> + SYSERROR("error bind-mounting %s to %s", abs_path,
> abs_path2);
> + goto out_error;
> + }
> +
> + free(abs_path);
> + free(abs_path2);
> + abs_path = NULL;
> + abs_path2 = NULL;
> +
> + /* add symlinks for every single subsystem */
> + if (subsystem_count > 1) {
> + for (i = 0; i < subsystem_count; i++) {
> + abs_path = lxc_append_paths(path, parts[i]);
> + if (!abs_path)
> + goto out_
Re: [lxc-devel] [PATCH 3/4] cgroup: Add lxc_setup_mount_cgroup to setup /sys/fs/cgroup inside the container
Hi Serge, >> Would you agree? > > Yup, sounds good. This email should probably be cut-pasted into the > lxc.conf man page then :) > > Should I apply the patch 4/4 as it stands now and the rest can be a > separate patch? > > Oh, one other thing is lxc.mount.auto needs to be added to > write_config(). Otherwise lxc-clone won't work on these, since > the new container won't have lxc.mount.auto. Yes, please apply patch 4/4 now (I don't think alpha2 is going to come out already tomorrow, right? ;-)) and tomorrow (or on Saturday) I'll prepare further patches for: - write_config support - cgroup-full - :ro/:rw/:mixed for cgroup/cgroup-full/sys - man page updates (List is mainly for myself so I don't forget anything.) Btw., speaking of man pages: /etc/lxc/lxc.conf isn't document at all so far... -- Christian -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] tests: Introduce lxc-test-concurrent for testing basic actions concurrently
Quoting S.Çağlar Onur (cag...@10ur.org):
> Signed-off-by: S.Çağlar Onur
Oh, great, thanks :)
Acked-by: Serge E. Hallyn
> ---
> .gitignore | 3 ++
> src/tests/Makefile.am | 6 ++-
> src/tests/concurrent.c | 116
> +
> 3 files changed, 123 insertions(+), 2 deletions(-)
> create mode 100644 src/tests/concurrent.c
>
> diff --git a/.gitignore b/.gitignore
> index 660756f..c005c4d 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -10,6 +10,7 @@
>
> .deps
> .libs
> +.dirstamp
>
> Makefile.in
> Makefile
> @@ -75,6 +76,7 @@ src/python-lxc/lxc/__pycache__/
>
> src/tests/lxc-test-cgpath
> src/tests/lxc-test-clonetest
> +src/tests/lxc-test-concurrent
> src/tests/lxc-test-console
> src/tests/lxc-test-containertests
> src/tests/lxc-test-createtest
> @@ -85,6 +87,7 @@ src/tests/lxc-test-locktests
> src/tests/lxc-test-lxcpath
> src/tests/lxc-test-saveconfig
> src/tests/lxc-test-shutdowntest
> +src/tests/lxc-test-snapshot
> src/tests/lxc-test-startone
> src/tests/lxc-usernic-test
>
> diff --git a/src/tests/Makefile.am b/src/tests/Makefile.am
> index a6dacab..8157407 100644
> --- a/src/tests/Makefile.am
> +++ b/src/tests/Makefile.am
> @@ -18,6 +18,7 @@ lxc_test_console_SOURCES = console.c
> lxc_usernic_test_SOURCES = ../lxc/lxc_user_nic.c ../lxc/nl.c
> lxc_usernic_test_CFLAGS = -DISTEST
> lxc_test_snapshot_SOURCES = snapshot.c
> +lxc_test_concurrent_SOURCES = concurrent.c
>
> AM_CFLAGS=-I$(top_srcdir)/src \
> -DLXCROOTFSMOUNT=\"$(LXCROOTFSMOUNT)\" \
> @@ -30,7 +31,7 @@ bin_PROGRAMS = lxc-test-containertests lxc-test-locktests
> lxc-test-startone \
> lxc-test-destroytest lxc-test-saveconfig lxc-test-createtest \
> lxc-test-shutdowntest lxc-test-get_item lxc-test-getkeys
> lxc-test-lxcpath \
> lxc-test-cgpath lxc-test-clonetest lxc-test-console lxc-usernic-test \
> - lxc-test-snapshot
> + lxc-test-snapshot lxc-test-concurrent
>
> bin_SCRIPTS = lxc-test-usernic
>
> @@ -51,4 +52,5 @@ EXTRA_DIST = \
> startone.c \
> console.c \
> lxc-test-usernic \
> - snapshot.c
> + snapshot.c \
> + concurrent.c
> diff --git a/src/tests/concurrent.c b/src/tests/concurrent.c
> new file mode 100644
> index 000..41c171b
> --- /dev/null
> +++ b/src/tests/concurrent.c
> @@ -0,0 +1,116 @@
> +/* concurrent.c
> + *
> + * Copyright © 2013 S.Çağlar Onur
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2, as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> + */
> +#include
> +#include
> +
> +#include "../lxc/lxccontainer.h"
> +
> +#define NTHREADS 5
> +
> +struct thread_args {
> +int thread_id;
> +int return_code;
> +char *mode;
> +};
> +
> +void * concurrent(void *arguments) {
> +char name[4];
> +struct thread_args *args = arguments;
> +struct lxc_container *c;
> +
> +sprintf(name, "%d", args->thread_id);
> +
> +c = lxc_container_new(name, NULL);
> +
> +args->return_code = 1;
> +if (strcmp(args->mode, "create") == 0) {
> +if (!c->is_defined(c)) {
> +if (!c->create(c, "ubuntu", NULL, NULL, 1, NULL)) {
> +fprintf(stderr, "Creating the container (%s) failed...\n",
> name);
> +goto out;
> +}
> +}
> +} else if(strcmp(args->mode, "start") == 0) {
> +if (c->is_defined(c) && !c->is_running(c)) {
> +c->want_daemonize(c);
> +if (!c->start(c, false, NULL)) {
> +fprintf(stderr, "Starting the container (%s) failed...\n",
> name);
> +goto out;
> +}
> +}
> +} else if(strcmp(args->mode, "stop") == 0) {
> +if (c->is_defined(c) && c->is_running(c)) {
> +if (!c->stop(c)) {
> +fprintf(stderr, "Stopping the container (%s) failed...\n",
> name);
> +goto out;
> +}
> +}
> +} else if(strcmp(args->mode, "destroy") == 0) {
> +if (c->is_defined(c) && !c->is_running(c)) {
> +if (!c->destroy(c)) {
> +fprintf(stderr, "Destroying the container (%s) failed...\n",
> name);
> +goto out;
> +}
> +}
> +}
> +args->return_code = 0;
> +out:
> +lxc_container_put(c);
> +pthread_exit(NULL);
> +}
> +
> +
> +int main(int argc, char *argv[]) {
> +int i, j;
> +pthread_attr
Re: [lxc-devel] [PATCH 1/4] utils: Add lxc_append_paths to join two paths.
Quoting Christian Seiler (christ...@iwakd.de):
> Signed-off-by: Christian Seiler
Acked-by: Serge E. Hallyn
> ---
> src/lxc/utils.c | 19 +++
> src/lxc/utils.h |1 +
> 2 files changed, 20 insertions(+)
>
> diff --git a/src/lxc/utils.c b/src/lxc/utils.c
> index 2e66585..78b234d 100644
> --- a/src/lxc/utils.c
> +++ b/src/lxc/utils.c
> @@ -658,6 +658,25 @@ char **lxc_normalize_path(const char *path)
> return components;
> }
>
> +char *lxc_append_paths(const char *first, const char *second)
> +{
> + size_t len = strlen(first) + strlen(second) + 1;
> + const char *pattern = "%s%s";
> + char *result = NULL;
> +
> + if (second[0] != '/') {
> + len += 1;
> + pattern = "%s/%s";
> + }
> +
> + result = calloc(1, len);
> + if (!result)
> + return NULL;
> +
> + snprintf(result, len, pattern, first, second);
> + return result;
> +}
> +
> bool lxc_string_in_list(const char *needle, const char *haystack, char _sep)
> {
> char *token, *str, *saveptr = NULL;
> diff --git a/src/lxc/utils.h b/src/lxc/utils.h
> index 9776d18..ba7cfb3 100644
> --- a/src/lxc/utils.h
> +++ b/src/lxc/utils.h
> @@ -219,6 +219,7 @@ extern char *lxc_string_join(const char *sep, const char
> **parts, bool use_as_pr
> * foo//bar -> { foo, bar, NULL }
> */
> extern char **lxc_normalize_path(const char *path);
> +extern char *lxc_append_paths(const char *first, const char *second);
> /* Note: the following two functions use strtok(), so they will never
> * consider an empty element, even if two delimiters are next to
> * each other.
> --
> 1.7.10.4
>
>
> --
> How ServiceNow helps IT people transform IT departments:
> 1. Consolidate legacy IT systems to a single system of record for IT
> 2. Standardize and globalize service processes across IT
> 3. Implement zero-touch automation to replace manual, redundant tasks
> http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk
> ___
> Lxc-devel mailing list
> Lxc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 3/4] cgroup: Add lxc_setup_mount_cgroup to setup /sys/fs/cgroup inside the container
Quoting Christian Seiler (christ...@iwakd.de): > Hi Serge, > > >> Would you agree? > > > > Yup, sounds good. This email should probably be cut-pasted into the > > lxc.conf man page then :) > > > > Should I apply the patch 4/4 as it stands now and the rest can be a > > separate patch? > > > > Oh, one other thing is lxc.mount.auto needs to be added to > > write_config(). Otherwise lxc-clone won't work on these, since > > the new container won't have lxc.mount.auto. > > Yes, please apply patch 4/4 now (I don't think alpha2 is going to come > out already tomorrow, right? ;-)) and tomorrow (or on Saturday) I'll No - I do use staging myself, but this won't break any existing installations so that's fine. > prepare further patches for: > > - write_config support > - cgroup-full > - :ro/:rw/:mixed for cgroup/cgroup-full/sys > - man page updates > > (List is mainly for myself so I don't forget anything.) Great, thanks. patch 4 pushed. > Btw., speaking of man pages: /etc/lxc/lxc.conf isn't document at all so > far... True. We've got a naming problem! -serge -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] f209d6: tests: Introduce lxc-test-concurrent for testing b...
Branch: refs/heads/staging Home: https://github.com/lxc/lxc Commit: f209d63a97a8a2df5324608fee7b0d7a494d69eb https://github.com/lxc/lxc/commit/f209d63a97a8a2df5324608fee7b0d7a494d69eb Author: S.Çağlar Onur Date: 2013-09-12 (Thu, 12 Sep 2013) Changed paths: M .gitignore M src/tests/Makefile.am A src/tests/concurrent.c Log Message: --- tests: Introduce lxc-test-concurrent for testing basic actions concurrently Signed-off-by: S.Çağlar Onur Signed-off-by: Serge Hallyn -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH 1/1] snapshots: add man page and fix up help info a bit.
Signed-off-by: Serge Hallyn
---
configure.ac | 1 +
doc/Makefile.am | 1 +
doc/lxc-snapshot.sgml.in | 152 +++
src/lxc/lxc_snapshot.c | 7 ++-
4 files changed, 158 insertions(+), 3 deletions(-)
create mode 100644 doc/lxc-snapshot.sgml.in
diff --git a/configure.ac b/configure.ac
index c734bea..6c74dcd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -414,6 +414,7 @@ AC_CONFIG_FILES([
doc/lxc-netstat.sgml
doc/lxc-ps.sgml
doc/lxc-restart.sgml
+ doc/lxc-snapshot.sgml
doc/lxc-start-ephemeral.sgml
doc/lxc-start.sgml
doc/lxc-stop.sgml
diff --git a/doc/Makefile.am b/doc/Makefile.am
index 2321a68..f2a106b 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -22,6 +22,7 @@ man_MANS = \
lxc-netstat.1 \
lxc-ps.1 \
lxc-restart.1 \
+ lxc-snapshot.1 \
lxc-start.1 \
lxc-stop.1 \
lxc-unfreeze.1 \
diff --git a/doc/lxc-snapshot.sgml.in b/doc/lxc-snapshot.sgml.in
new file mode 100644
index 000..f66070b
--- /dev/null
+++ b/doc/lxc-snapshot.sgml.in
@@ -0,0 +1,152 @@
+
+
+
+
+]>
+
+
+
+ @LXC_GENERATE_DATE@
+
+
+lxc-snapshot
+1
+
+
+
+lxc-snapshot
+
+
+ Snapshot an existing container.
+
+
+
+
+
+ lxc-snapshot
+ -n, --name name
+ -c, --comment file
+
+
+ lxc-snapshot
+ -n, --name name
+ -L, --list
+ -C, --showcomments
+
+
+ lxc-snapshot
+ -n, --name name
+ -r, -restore
snapshot-name
+newname
+
+
+
+
+Description
+
+
+ lxc-snapshot creates, lists, and restores
+ container snapshots.
+
+
+Snapshots are stored as snapshotted containers under a private
configuration path. For instance, if the container's configuration path is
/var/lib/lxc and the container is c1,
then the first snapshot will be stored as container snap0
under configuration path /var/lib/lxcsnaps/c1.
+
+
+
+
+
+Options
+
+
+
+
+-c,--comment
comment_file
+
+Associate the comment in
comment_file with the newly created snapshot.
+
+
+
+
+-L,--list
+
+List existing snapshots.
+
+
+
+
+-C,--showcomments
+
+Show snapshot comments in the snapshots listings.
+
+
+
+
+-r,--restore snapshot-name
+
+Restore the named snapshot, meaning a full new container is
created which is a copy of the snapshot.
+
+
+
+
+newname
+
+When restoring a snapshot, the last optional argument is the
name to use for the restored container. If no name is given, then the original
container will be destroyed and the restored container will take its place.
Note that deleting the original snapshot is not possible in the case of
overlayfs or zfs backed snapshots.
+
+
+
+
+
+
+
+ &commonoptions;
+
+ &seealso;
+
+
+Author
+Serge Hallyn serge.hal...@ubuntu.com
+
+
+
+
+
diff --git a/src/lxc/lxc_snapshot.c b/src/lxc/lxc_snapshot.c
index 05562f0..0177f5d 100644
--- a/src/lxc/lxc_snapshot.c
+++ b/src/lxc/lxc_snapshot.c
@@ -129,13 +129,14 @@ static const struct option my_longopts[] = {
static struct lxc_arguments my_args = {
- .progname = "lxc-create",
+ .progname = "lxc-snapshot",
.help = "\
---name=NAME [-w] [-r] [-t timeout] [-P lxcpath]\n\
+--name=NAME [-P lxcpath] [-L [-C]] [-c commentfile] [-r snapname [newname]]\n\
\n\
-lxc-create creates a container\n\
+lxc-snapshot snapshots a container\n\
\n\
Options :\n\
+ -n, --name=NAME NAME for name of the container\n\
-L, --list list snapshots\n\
-C, --showcomments show snapshot comments in list\n\
-c, --comment=file add file as a comment\n\
--
1.8.1.2
--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH] Change rootfs pinning mechnism
Chane pinning mechanism: Use $rootfs/lxc.hold instead of $rootfs.hold
(in case $rootfs is a mountpoint itself), but delete the file
immediately after creating it (but keep it open). This will keep the
root filesystem busy but does not leave any unnecessary files lying
around.
Signed-off-by: Christian Seiler
---
src/lxc/conf.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 5f9ae87..291ea6f 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -670,9 +670,10 @@ static int mount_rootfs_block(const char *rootfs, const
char *target)
/*
* pin_rootfs
- * if rootfs is a directory, then open ${rootfs}.hold for writing for the
- * duration of the container run, to prevent the container from marking the
- * underlying fs readonly on shutdown.
+ * if rootfs is a directory, then open ${rootfs}/lxc.hold for writing for
+ * the duration of the container run, to prevent the container from marking
+ * the underlying fs readonly on shutdown. unlink the file immediately so
+ * no name pollution is happens
* return -1 on error.
* return -2 if nothing needed to be pinned.
* return an open fd (>=0) if we pinned it.
@@ -699,11 +700,14 @@ int pin_rootfs(const char *rootfs)
if (!S_ISDIR(s.st_mode))
return -2;
- ret = snprintf(absrootfspin, MAXPATHLEN, "%s%s", absrootfs, ".hold");
+ ret = snprintf(absrootfspin, MAXPATHLEN, "%s/lxc.hold", absrootfs);
if (ret >= MAXPATHLEN)
return -1;
fd = open(absrootfspin, O_CREAT | O_RDWR, S_IWUSR|S_IRUSR);
+ if (fd < 0)
+ return fd;
+ (void)unlink(absrootfspin);
return fd;
}
--
1.7.10.4
--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 3/4] cgroup: Add lxc_setup_mount_cgroup to setup /sys/fs/cgroup inside the container
Quoting Christian Seiler (christ...@iwakd.de):
> Hi Serge,
>
> > Ah, no, mountall just gets upset about some forced readonly
> > mounts. lxc.mount.auto = proc always worked for me. If I do
> >
> > - r = mount("sysfs", path, "sysfs", MS_RDONLY, NULL);
> > + r = mount("sysfs", path, "sysfs", 0, NULL);
> > - mount(NULL, path, NULL, MS_REMOUNT|MS_RDONLY, NULL);
> > + //mount(NULL, path, NULL, MS_REMOUNT|MS_RDONLY, NULL);
> > then sys and cgroup auto-mount also work. The problem with both is that
> > mountall has entries in /lib/init/fstab saying they should be mounted
> > readwrite, so it hangs trying to force that to happen.
>
> Ah, ok... :/
>
> > How would you feel about adding a flag to specify whether they should be
> > readonly? How would we specify the flag? (Note it's ok for sys to be
> > read-write in ubuntu since apparmor confines it. cgroups by default are
> > too, but we don't have a good way yet to generate policy which will allow
> > /sys/fs/cgroup/$controller/$container-cgroup-path/ to be written to but the
> > /sys/fs/cgroup/$controller not)
>
> I could get behind the following:
>
>proc- always read-write (no harm AFAICT)
>sys - default: read-only
>sys:rw - read-write
>sys:ro - explicit read-only
>cgroup:ro - completely ro (including paths)
>cgroup:rw - completely rw (including paths)
That sounds good.
>cgroup:mixed- paths ro, other rw
what is 'paths' vs. 'other' here? There's
/sys/fs/cgroup
itself,
/sys/fs/cgroup/$subsys
then the paths up to the container's own path, and then
there's the stuff under the container's own path. I'm not
clear on which you're calling what.
>cgroup - defaults to cgroup:mixed
>
> Also, I could imagine adding
>
>cgroup-full:ro- mount complete tree read-only (not just partial)
>cgroup-full:rw- mount complete tree read-write (not just partial)
>cgroup-full:mixed - mount complete tree read-only but bind-mount
>partial tree read-write
>cgroup-full - defaults to cgroup-full: mixed
Hm, but you're doing the full tree by default. What is the difference
between this and cgroup:ro?
thanks,
-serge
--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 3/4] cgroup: Add lxc_setup_mount_cgroup to setup /sys/fs/cgroup inside the container
Quoting Christian Seiler (christ...@iwakd.de): > Hi Serge, > > >> I could get behind the following: > >> > >>proc- always read-write (no harm AFAICT) > >>sys - default: read-only > >>sys:rw - read-write > >>sys:ro - explicit read-only > >>cgroup:ro - completely ro (including paths) > >>cgroup:rw - completely rw (including paths) > > > > That sounds good. > > > >>cgroup:mixed- paths ro, other rw > > > > what is 'paths' vs. 'other' here? There's > > > > /sys/fs/cgroup > > > > itself, > > > > /sys/fs/cgroup/$subsys > > > > then the paths up to the container's own path, and then > > there's the stuff under the container's own path. I'm not > > clear on which you're calling what. > > What I meant is that mixed is the current staging behaviour, i.e. > > - /sys/fs/cgroup: tmpfs, ro after setup > - /sys/fs/cgroup/$subsys/$container_cgroup: bind-mount, rw > > So that /sys/fs/cgroup is r/o, /sys/fs/cgroup/$subsys is r/o, > /sys/fs/cgroup/$subsys/$parent_of_container_cgroup is r/o but > /sys/fs/cgroup/$subsys/$container_cgroup is r/w. > > >>cgroup-full:ro- mount complete tree read-only (not just partial) > >>cgroup-full:rw- mount complete tree read-write (not just partial) > >>cgroup-full:mixed - mount complete tree read-only but bind-mount > >>partial tree read-write > >>cgroup-full - defaults to cgroup-full: mixed > > > > Hm, but you're doing the full tree by default. What is the difference > > between this and cgroup:ro? > > cgroup-full:mixed would be: > > - /sys/fs/cgroup: tmpfs, ro > - /sys/fs/cgroup/$subsys bind-mount, ro > - /sys/fs/cgroup/$subsys/$container_cgroup bind-mount, rw > > That has the advantage that /sys/fs/cgroup/$subsys is actually a cgroup > filesystem (even though it's read-only), which may improve compatibility > compared to the current behavior, but the disadvantage that the names of > all cgroups of the host (including those in other containers) leak into > the container (even though the container can't really do anything with > them, if it doesn't have mount permissions). > > cgroup-full:rw would just mount everything into /sys/fs/cgroup as it > should be according to the standard and make everything read-write. > > cgroup-full:ro would do the same as cgroup-full:rw but read-only. > > It then depends on the policy of the administrator and the compatibility > level of software that is to be run in the container what option should > be chosen. > > Would you agree? Yup, sounds good. This email should probably be cut-pasted into the lxc.conf man page then :) Should I apply the patch 4/4 as it stands now and the rest can be a separate patch? Oh, one other thing is lxc.mount.auto needs to be added to write_config(). Otherwise lxc-clone won't work on these, since the new container won't have lxc.mount.auto. thanks, -serge -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] regression: lxc-start -d hangs in lxc_monitor_sock_name (at process_lock)
Thanks. A few days ago I wrote a short-n-simple little program that cloned two thread which each did some things with containers. It was definately racy. Based on your input I"ll take a closer look at the new monitoring code. I'm hoping to take a much closer look next week. I.e. load two containers, and fork threads just to do c->is_defined; just c->wait; just c->daemonize; just c->start(); etc. and see which ones are racy after a few runs. Quoting S.Çağlar Onur (cag...@10ur.org): > Hi, > > I think staging (my head is @ 813a48...) started to stuck while creating > containers concurrently after monitoring related changes. > > I observed that issue with the Go bindings first. Then I wrote a test case > to remove Go from the picture and I also thought that having a test case > would be helpful (see "[PATCH] tests: Introduce lxc-test-concurrent for > testing basic actions concurrently"). > > Normally one should see following > > [caglar@qgq:~/Projects/lxc(staging)] sudo lxc-test-concurrent > > Executing (create) for 5 containers... > > Executing (start) for 5 containers... > > Executing (stop) for 5 containers... > > Executing (destroy) for 5 containers... > > > but occasionally create started to stuck on my test system (just try to run > couple of times). > > Cheers, > > > > On Thu, Sep 12, 2013 at 10:41 AM, Serge Hallyn wrote: > > > Quoting Dwight Engen (dwight.en...@oracle.com): > > > On Thu, 12 Sep 2013 00:27:04 -0400 > > > Stéphane Graber wrote: > > > > > > > Hello, > > > > > > > > It looks like Dwight's last change introduce a bit of a regression > > > > when running lxc-start -d. > > > > > > Yikes, sorry I didn't catch that in my testing. My follow on patch > > > for doing the monitor socket in the abstract space gets rid of this > > > entirely, so this is an additional reason to consider it. > > > > > > > Tracing it down (added a ton of printf all over), it looks like it's > > > > hanging on: > > > > - lxcapi_start > > > >- wait_on_daemonized_start > > > > - lxcapi_wait > > > >- lxc_wait > > > > - lxc_monitor_open > > > >- lxc_monitor_sock_name > > > > > > > > Specifically, it's hanging at the process_lock() call because > > > > process_lock() was already called as part of lxcapi_start and only > > > > gets unlocked right after wait_on_daemonized_start returns. > > > > > > > > > > > > Looking at the code, I'm not even sure why we need process_lock there. > > > > What it protects is another thread triggering the mkdir_p in parallel, > > > > but that shouldn't really be a problem since running two mkdir_p at > > > > the same time should still result in the hierarchy being created, or > > > > did I miss something? > > > > > > That sounds logical to me, but hmm, does that mean we don't need it in > > > lxclock_name() either (where I was modeling this on)? I wonder if > > > there is a code flow that its possible for us to hang there. > > > > Well mkdir uses the umask right? (and *may* use the cwd). Both of > > which are shared among threads. It won't set them, but something else > > might change them underneath them. > > > > So I could be wrong and we might not need it, but it seemed like we > > might. > > > > -serge > > > > > > -- > > How ServiceNow helps IT people transform IT departments: > > 1. Consolidate legacy IT systems to a single system of record for IT > > 2. Standardize and globalize service processes across IT > > 3. Implement zero-touch automation to replace manual, redundant tasks > > http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk > > ___ > > Lxc-devel mailing list > > Lxc-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/lxc-devel > > > > > > -- > S.Çağlar Onur -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 3/4] cgroup: Add lxc_setup_mount_cgroup to setup /sys/fs/cgroup inside the container
Hi Serge, Am 12.09.2013 16:43, schrieb Serge Hallyn: > Quoting Christian Seiler (christ...@iwakd.de): >> Add funbction to mount cgroup filesystem hierarchy into the >> container, >> allowing only access to the parts that the container should have >> access >> to, but none else. >> >> Signed-off-by: Christian Seiler > > Hm, these last two patches aren't working for me. They don't break > anything in a normal setup, but when I try use lxc.mount.auto it > hangs. It may not be a fault in the patches, as mountall starts and > hangs. It may be that the image you are using doesn't like what one of the auto-mounted filesystems is doing. It could be that if you manually add the same entry to lxc.mount.entry, it would also hang. Could you try to test the patch itself by doing: lxc-start -n $NAME -- /bin/cat /proc/self/mountinfo If some distro images break when using auto-mounting of this stuff, it should be up to the administrators (and/or template creators) to decide whether to use it or not. -- Christian -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH] tests: Introduce lxc-test-concurrent for testing basic actions concurrently
Signed-off-by: S.Çağlar Onur
---
.gitignore | 3 ++
src/tests/Makefile.am | 6 ++-
src/tests/concurrent.c | 116 +
3 files changed, 123 insertions(+), 2 deletions(-)
create mode 100644 src/tests/concurrent.c
diff --git a/.gitignore b/.gitignore
index 660756f..c005c4d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,6 +10,7 @@
.deps
.libs
+.dirstamp
Makefile.in
Makefile
@@ -75,6 +76,7 @@ src/python-lxc/lxc/__pycache__/
src/tests/lxc-test-cgpath
src/tests/lxc-test-clonetest
+src/tests/lxc-test-concurrent
src/tests/lxc-test-console
src/tests/lxc-test-containertests
src/tests/lxc-test-createtest
@@ -85,6 +87,7 @@ src/tests/lxc-test-locktests
src/tests/lxc-test-lxcpath
src/tests/lxc-test-saveconfig
src/tests/lxc-test-shutdowntest
+src/tests/lxc-test-snapshot
src/tests/lxc-test-startone
src/tests/lxc-usernic-test
diff --git a/src/tests/Makefile.am b/src/tests/Makefile.am
index a6dacab..8157407 100644
--- a/src/tests/Makefile.am
+++ b/src/tests/Makefile.am
@@ -18,6 +18,7 @@ lxc_test_console_SOURCES = console.c
lxc_usernic_test_SOURCES = ../lxc/lxc_user_nic.c ../lxc/nl.c
lxc_usernic_test_CFLAGS = -DISTEST
lxc_test_snapshot_SOURCES = snapshot.c
+lxc_test_concurrent_SOURCES = concurrent.c
AM_CFLAGS=-I$(top_srcdir)/src \
-DLXCROOTFSMOUNT=\"$(LXCROOTFSMOUNT)\" \
@@ -30,7 +31,7 @@ bin_PROGRAMS = lxc-test-containertests lxc-test-locktests
lxc-test-startone \
lxc-test-destroytest lxc-test-saveconfig lxc-test-createtest \
lxc-test-shutdowntest lxc-test-get_item lxc-test-getkeys
lxc-test-lxcpath \
lxc-test-cgpath lxc-test-clonetest lxc-test-console lxc-usernic-test \
- lxc-test-snapshot
+ lxc-test-snapshot lxc-test-concurrent
bin_SCRIPTS = lxc-test-usernic
@@ -51,4 +52,5 @@ EXTRA_DIST = \
startone.c \
console.c \
lxc-test-usernic \
- snapshot.c
+ snapshot.c \
+ concurrent.c
diff --git a/src/tests/concurrent.c b/src/tests/concurrent.c
new file mode 100644
index 000..41c171b
--- /dev/null
+++ b/src/tests/concurrent.c
@@ -0,0 +1,116 @@
+/* concurrent.c
+ *
+ * Copyright © 2013 S.Çağlar Onur
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+#include
+#include
+
+#include "../lxc/lxccontainer.h"
+
+#define NTHREADS 5
+
+struct thread_args {
+int thread_id;
+int return_code;
+char *mode;
+};
+
+void * concurrent(void *arguments) {
+char name[4];
+struct thread_args *args = arguments;
+struct lxc_container *c;
+
+sprintf(name, "%d", args->thread_id);
+
+c = lxc_container_new(name, NULL);
+
+args->return_code = 1;
+if (strcmp(args->mode, "create") == 0) {
+if (!c->is_defined(c)) {
+if (!c->create(c, "ubuntu", NULL, NULL, 1, NULL)) {
+fprintf(stderr, "Creating the container (%s) failed...\n",
name);
+goto out;
+}
+}
+} else if(strcmp(args->mode, "start") == 0) {
+if (c->is_defined(c) && !c->is_running(c)) {
+c->want_daemonize(c);
+if (!c->start(c, false, NULL)) {
+fprintf(stderr, "Starting the container (%s) failed...\n",
name);
+goto out;
+}
+}
+} else if(strcmp(args->mode, "stop") == 0) {
+if (c->is_defined(c) && c->is_running(c)) {
+if (!c->stop(c)) {
+fprintf(stderr, "Stopping the container (%s) failed...\n",
name);
+goto out;
+}
+}
+} else if(strcmp(args->mode, "destroy") == 0) {
+if (c->is_defined(c) && !c->is_running(c)) {
+if (!c->destroy(c)) {
+fprintf(stderr, "Destroying the container (%s) failed...\n",
name);
+goto out;
+}
+}
+}
+args->return_code = 0;
+out:
+lxc_container_put(c);
+pthread_exit(NULL);
+}
+
+
+int main(int argc, char *argv[]) {
+int i, j;
+pthread_attr_t attr;
+pthread_t threads[NTHREADS];
+struct thread_args args[NTHREADS];
+
+char *modes[] = {"create", "start", "stop", "destroy", NULL};
+
+pthread_attr_init(&attr);
+pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_JOINABLE);
+
+for (i = 0; modes[i];i++) {
+printf("Executing (%s) for %d containers...\n", modes[i], NTHREADS);
+for (j = 0
Re: [lxc-devel] [PATCH 3/4] cgroup: Add lxc_setup_mount_cgroup to setup /sys/fs/cgroup inside the container
Quoting Christian Seiler (christ...@iwakd.de):
> Hi Serge,
>
> Am 12.09.2013 16:43, schrieb Serge Hallyn:
> >Quoting Christian Seiler (christ...@iwakd.de):
> >>Add funbction to mount cgroup filesystem hierarchy into the
> >>container,
> >>allowing only access to the parts that the container should have
> >>access
> >>to, but none else.
> >>
> >>Signed-off-by: Christian Seiler
> >
> >Hm, these last two patches aren't working for me. They don't break
> >anything in a normal setup, but when I try use lxc.mount.auto it
> >hangs. It may not be a fault in the patches, as mountall starts and
> >hangs.
>
> It may be that the image you are using doesn't like what one
> of the auto-mounted filesystems is doing. It could be that if
Ah, no, mountall just gets upset about some forced readonly
mounts. lxc.mount.auto = proc always worked for me. If I do
ubuntu@c-saucy-1:~/lxc-0.9.0.0~staging~20130911-2324$ git diff src/lxc/conf.c
diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 364e571..708bb48 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -762,7 +762,7 @@ static int lxc_mount_auto_mounts(struct lxc_conf *conf, int
flags, struct cgroup
goto cleanup;
}
- r = mount("sysfs", path, "sysfs", MS_RDONLY, NULL);
+ r = mount("sysfs", path, "sysfs", 0, NULL);
if (r < 0) {
SYSERROR("error mounting /sys");
goto cleanup;
and
ubuntu@c-saucy-1:~/lxc-0.9.0.0~staging~20130911-2324$ git diff src/lxc/cgroup.c
diff --git a/src/lxc/cgroup.c b/src/lxc/cgroup.c
index 876c60c..a2ed467 100644
--- a/src/lxc/cgroup.c
+++ b/src/lxc/cgroup.c
@@ -1310,7 +1310,7 @@ int lxc_setup_mount_cgroup(const char *root, struct
cgroup_process_info *base_in
* new cgroups outside the allowed area fails with an error instead
* of simply causing this to create directories in the tmpfs itself)
*/
- mount(NULL, path, NULL, MS_REMOUNT|MS_RDONLY, NULL);
+ //mount(NULL, path, NULL, MS_REMOUNT|MS_RDONLY, NULL);
free(path);
then sys and cgroup auto-mount also work. The problem with both is that
mountall has entries in /lib/init/fstab saying they should be mounted
readwrite, so it hangs trying to force that to happen.
How would you feel about adding a flag to specify whether they should be
readonly? How would we specify the flag? (Note it's ok for sys to be
read-write in ubuntu since apparmor confines it. cgroups by default are
too, but we don't have a good way yet to generate policy which will allow
/sys/fs/cgroup/$controller/$container-cgroup-path/ to be written to but the
/sys/fs/cgroup/$controller not)
-serge
--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 3/4] cgroup: Add lxc_setup_mount_cgroup to setup /sys/fs/cgroup inside the container
Hi Serge,
> Ah, no, mountall just gets upset about some forced readonly
> mounts. lxc.mount.auto = proc always worked for me. If I do
>
> - r = mount("sysfs", path, "sysfs", MS_RDONLY, NULL);
> + r = mount("sysfs", path, "sysfs", 0, NULL);
> - mount(NULL, path, NULL, MS_REMOUNT|MS_RDONLY, NULL);
> + //mount(NULL, path, NULL, MS_REMOUNT|MS_RDONLY, NULL);
> then sys and cgroup auto-mount also work. The problem with both is that
> mountall has entries in /lib/init/fstab saying they should be mounted
> readwrite, so it hangs trying to force that to happen.
Ah, ok... :/
> How would you feel about adding a flag to specify whether they should be
> readonly? How would we specify the flag? (Note it's ok for sys to be
> read-write in ubuntu since apparmor confines it. cgroups by default are
> too, but we don't have a good way yet to generate policy which will allow
> /sys/fs/cgroup/$controller/$container-cgroup-path/ to be written to but the
> /sys/fs/cgroup/$controller not)
I could get behind the following:
proc- always read-write (no harm AFAICT)
sys - default: read-only
sys:rw - read-write
sys:ro - explicit read-only
cgroup:ro - completely ro (including paths)
cgroup:rw - completely rw (including paths)
cgroup:mixed- paths ro, other rw
cgroup - defaults to cgroup:mixed
Also, I could imagine adding
cgroup-full:ro- mount complete tree read-only (not just partial)
cgroup-full:rw- mount complete tree read-write (not just partial)
cgroup-full:mixed - mount complete tree read-only but bind-mount
partial tree read-write
cgroup-full - defaults to cgroup-full: mixed
Thoughts?
-- Christian
--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] b45c70: hash lxcname for use in monitor unix socket sun_pa...
Branch: refs/heads/staging Home: https://github.com/lxc/lxc Commit: b45c701178cdc705d26c95f31035c39bab9edf20 https://github.com/lxc/lxc/commit/b45c701178cdc705d26c95f31035c39bab9edf20 Author: Dwight Engen Date: 2013-09-12 (Thu, 12 Sep 2013) Changed paths: M src/lxc/monitor.c Log Message: --- hash lxcname for use in monitor unix socket sun_path[108] - Also convert to unix abstract socket - A simple FNV hash is used instead of SHA-1 since we may not HAVE_GNUTLS Signed-off-by: Dwight Engen Signed-off-by: Serge Hallyn -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 813a48: snapshots: add man page and fix up help info a bit...
Branch: refs/heads/staging Home: https://github.com/lxc/lxc Commit: 813a4837659d5d7a2c0d0abe03c87196747217e9 https://github.com/lxc/lxc/commit/813a4837659d5d7a2c0d0abe03c87196747217e9 Author: Serge Hallyn Date: 2013-09-12 (Thu, 12 Sep 2013) Changed paths: M configure.ac M doc/Makefile.am A doc/lxc-snapshot.sgml.in M src/lxc/lxc_snapshot.c Log Message: --- snapshots: add man page and fix up help info a bit. Signed-off-by: Serge Hallyn Acked-by: Stéphane Graber -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [Lxc-users] Working LXC templates? EUREAKA! I think I've got it!
On Thu, 2013-09-12 at 15:23 -0400, Michael H. Warfield wrote:
> All - Especially Tony Su,
> Couple of people where I work thought you couldn't do what I was trying
> to do, that it was "impossible". Oh well. Looks like they were
> wrong. :-P It may not be "efficient" but it can be made to work.
Never fails, I swear, it never fails. Not minutes after I posted this
original message, one of my test runs blew an error that pointed out a
typo that pointed out six other spots where I had environment variables
out of sync and, after fixing them, I realized I had missed several
update paths. And then there were the initialization checks I missed.
Would work fine on fedora on fedora but not what my target was.
Ok... So... I fixed all that. The attached template should actually
work if you're not on a Fedora host (I hope).
It does dawn on me that all this effort really is a "one trick pony"
and, once it has built the very first container, is no longer needed
after the first run. Reason? Each container built can be a run time
environment to build new containers.
So... Before I submit an actual patch back to the upstream project,
I'll probably scope out the logic to scan the cached containers for the
most appropriate container and use it for the RTE and never use the
cached install RTE again.
This may also be appropriate for other templates. Once you've
bootstrapped the template process, you may not need the bootstrap again.
Just build and cache your best shot and use it in the future.
I have tested this template and built containers from F14 through F19.
F15 failed but, I already know it would not have run as a container
anyways because of the horribly broken and incompatible systemd in that
distro. Prior to F14, some versions will build and some won't.
Shouldn't be a problem with Fedora on Fedora and anything prior to F18
is past EOL anyways, so why should I care?
IAC... Please discard the previous template. Here is my current
template. And please test it.
Thanks!
Regards,
Mike
> Way down below, in-line...
>
> On Mon, 2013-09-09 at 07:28 -0400, Michael H. Warfield wrote:
> > On Mon, 2013-09-09 at 08:58 +0200, Natanael Copa wrote:
> > > On Sun, 08 Sep 2013 20:33:16 -0400
> > > "Michael H. Warfield" wrote:
> > >
> > > > With all due respect...
> > > >
> > > > On Sun, 2013-09-08 at 16:08 -0700, Tony Su wrote:
> > > > > After putting some thought into this,
> > > > > IMO LXC badly needs a universal tool with the following features
> > > > >
> > > > > - A single script should be used to run on HostOS, creating
> > > > > supported Container OS. Although this would make the script
> > > > > extremely large, IMO it would actually be easier to maintain in the
> > > > > long run.
> > > >
> > > > Actually, no. From my experience (30+ years in software development),
> > > > it would turn into a morass.
> > > >
> > > > The problem here is that the maintainer(s) would then need to understand
> > > > how each and every distribution is installed and how it would be
> > > > installed on each and every distribution. It would distill the worse of
> > > > all the problems we have now in the templates into one great big dung
> > > > pile. It would rapidly become unmaintainable. The "extremely large" is
> > > > the red letter warning that it will become unmaintainable as fewer and
> > > > fewer people understand what this great big huge blob does.
> >
> > > I tend to agree with this.
>
> > > What I do think could be done is to use template APIs. Either by having
> > > a script "library" with helper functions (for things like:
> > > generate_mac_address etc) or let the template scripts be "plugins" that
> > > must provide a set of pre-defined functions (eg. install_distro,
> > > configure_distro, copy_configuration etc) or maybe a combination of
> > > those two.
>
> > I like this idea, it's just that, in the short term, we have to get past
> > this one gotcha.
>
> > In the git-stage current Fedora template, the entire problem is embodied
> > in the "download_fedora" function starting around line 201... The
> > gotcha's are three commands around line 272 after we've identified and
> > downloaded the initial release rpm. We have this:
> >
> > mkdir -p $INSTALL_ROOT/var/lib/rpm
> > rpm --root $INSTALL_ROOT --initdb
> > rpm --root $INSTALL_ROOT -ivh ${INSTALL_ROOT}/${RELEASE_RPM}
> > $YUM install $PKG_LIST
>
> > Ok... Those are running in the host local run time environment.
> > Obviously, if the host does not have a (compatible) version of rpm
> > and/or yum in the host local environment, you're screwed. That's the
> > catch-22 situation and it's the same situation with zypper in the
> > OpenSuse template. That short space of code has to be recreated in a
> > totally distro-agnostic manner so it runs on any distro to create our
> > initial rootfs. After that, we can do what ever distro (Fedora)
> > specific commands we want by chrooting into the target container first
