On Tue, Dec 12, 2017 at 11:00:01PM -0600, Serge Hallyn wrote: > On Tue, Dec 05, 2017 at 05:20:32PM +0100, Dirk Geschke wrote: > > Hi Serge, > > > > > > I am a little bit clueless, I have several systems running with > > > > Debian and unprivileged LXC. But newer systems won't start new > > > > containers. > > > > > > > > Actually I have a Debian stretch, installed the normal way but > > > > with lxc-2.0.9 and cgmanager-0.41 installed from sources. > > > > > > > > I can setup cgmanager, can do a cgm movepid and it is no problem > > > > to download a template. But starting the container does not work, > > > > it simply hungs at: > > > > > > > > $ lxc-start -n lxc-test -l trace -o wheezy -F > > > > > > I see no bad errors in the log. When this hangs, can you > > > from another terminal see whether 'lxc-ls -f' shows it > > > running, and what 'lxc-attach -n lxc-test' does? > > > > that's the funny part: Nothing. There is not one process from > > the subuid range running. It simply hangs before it tries to > > start the container at all. And I have no idea, why. > > But with lxc-2.0.8 it works. > > > > I just installed and started debian wheezy, upgraded it to jessie > > and finally to stretch. It works fine. > > > > I now installed lxc-2.0.9 again, tried to start the container again > > and nothing happens: > > > > $ lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F > > > > That's all. lxc-ls -f and lxc-attach-n lxc-test hangs, too. > > > > I see also three processes of lxc-start: > > > > $ ps waux |grep lxc-start > > lxc-test 24478 0.0 0.1 51740 4232 pts/0 S+ 17:16 0:00 > > lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F > > lxc-test 24487 0.0 0.0 51740 504 pts/0 S+ 17:16 0:00 > > lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F > > lxc-test 24492 0.0 0.0 51740 508 pts/0 S+ 17:16 0:00 > > lxc-start -n lxc-test -l trace -o stretch-lxc-2.0.9 -F > > When you gdb-attach to these (which you have to do as root for two > of them) you find that you're hung on: > > (gdb) where > #0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 > #1 0x00007f2a94f68b95 in __GI___pthread_mutex_lock > (mutex=mutex@entry=0x7f2a95868a60 <cgm_mutex>) > at ../nptl/pthread_mutex_lock.c:80 > #2 0x00007f2a95638c4d in lock_mutex (l=0x7f2a95868a60 <cgm_mutex>) at > cgroups/cgmanager.c:80 > #3 cgm_lock () at cgroups/cgmanager.c:98 > #4 0x00007f2a94a722f5 in __libc_fork () at ../sysdeps/nptl/fork.c:96 > #5 0x00007f2a95604ee7 in run_command (buf=buf@entry=0x7fff3b5a20e0 "", > buf_size=buf_size@entry=4096, > child_fn=child_fn@entry=0x7f2a95606a30 <lxc_map_ids_exec_wrapper>, > args=args@entry=0x7fff3b5a40e0) at utils.c:2262 > #6 0x00007f2a9560b01e in lxc_map_ids (idmap=idmap@entry=0x55b48a62c1c0, > pid=pid@entry=15389) > at conf.c:2652 > #7 0x00007f2a9560f1e5 in userns_exec_1 (conf=conf@entry=0x55b48a625b90, > fn=fn@entry=0x7f2a95639a20 <chown_cgroup_wrapper>, > data=data@entry=0x7fff3b5a5210, > fn_name=fn_name@entry=0x7f2a9563fadc "chown_cgroup_wrapper") at > conf.c:3822 > #8 0x00007f2a9563a1a9 in chown_cgroup (conf=0x55b48a625b90, > cgroup_path=<optimized out>) > at cgroups/cgmanager.c:500 > #9 cgm_chown (hdata=0x55b48a62b1d0, conf=0x55b48a625b90) at > cgroups/cgmanager.c:1555 > #10 0x00007f2a955fa397 in lxc_spawn (handler=0x55b48a624e50) at start.c:1363 > > and > > #0 0x00007f2a94f6f1f0 in __read_nocancel () at > ../sysdeps/unix/syscall-template.S:84 > #1 0x00007f2a95607872 in run_userns_fn (data=0x7fff3b5a51b0) at conf.c:3570 > #2 0x00007f2a94aa2aff in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 > > So it seems to be hanging on cgm_lock(). > > I'm a bit too tired to think it through clearly enough, but I'm thinking > this might have to do with the introduction of run_command(). It introduces > an extra fork() between the clone(CLONE_NEWUSER)'d thread and the task which > actually does the work. Perhaps that is messing with our lock state?
I mean, one *could* attribute it to the pthread atfork handler... Let me take a look at run_command(). _______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users