[lxc-users] Cannot setup thread local storage unknown error
Vivek Singh
vivek.siwan at gmail.com
Tue Jan 7 06:18:04 UTC 2014
To make seccomp.full file I coppied all syscall numbers from unistd.h . If
I remove seccomp.full file from lxc.conf it works fine . But with
seccomp.full in lxc config it fails
On Jan 7, 2014 11:41 AM, "Vivek Singh" <vivek.siwan at gmail.com> wrote:
> 1. It is running with --disable -seccomp option.
> 2. My target is not havving implementation of syscall no
> 254(set_thread_area ()) and 255(get_thread_area ()).
> 3. I tried to run lxc with CLONE_SETTLS option but is ia crshing may be
> due to non existence of syscall 254 and 255.
>
> Vivek
> On Jan 3, 2014 5:30 PM, <lxc-users-request at lists.linuxcontainers.org>
> wrote:
>
>> Send lxc-users mailing list submissions to
>> lxc-users at lists.linuxcontainers.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://lists.linuxcontainers.org/listinfo/lxc-users
>> or, via email, send a message with subject or body 'help' to
>> lxc-users-request at lists.linuxcontainers.org
>>
>> You can reach the person managing the list at
>> lxc-users-owner at lists.linuxcontainers.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of lxc-users digest..."
>>
>> Today's Topics:
>>
>> 1. Re: Cannot set up thread local storage: unknown error
>> (Serge Hallyn)
>> 2. lxc-start hangs with no output (Piotr Isajew)
>> 3. Cannot stop busybox container (Kevin Wilson)
>> 4. Re: lxc-start hangs with no output (Giuseppe Tofoni)
>> 5. Re: lxc-start hangs with no output (Piotr Isajew)
>>
>>
>> ---------- Forwarded message ----------
>> From: Serge Hallyn <serge.hallyn at ubuntu.com>
>> To: LXC users mailing-list <lxc-users at lists.linuxcontainers.org>
>> Cc:
>> Date: Thu, 2 Jan 2014 09:34:22 -0600
>> Subject: Re: [lxc-users] Cannot set up thread local storage: unknown error
>> Quoting Vivek Singh (vivek.siwan at gmail.com):
>> > Hello,
>> > I am very new to lxc container. When I am trying to run it with
>> libseccomp
>> > on my arm target it produces following error with command.
>> > "Lxc-execute -n name ls"
>> > "Cannot set up thread-local storage unknown error".
>> >
>> > Please provide your suggestions to me so that I can proceed forward.
>>
>> Confirm that it doesn't work with seccomp disabled. Run lxc-execute
>> with '-l info -o outout' and look for information in outout as well
>> as in syslog.
>>
>> Looking at arch/arm/include/uapi/asm/unist.h, you might need to allow
>> syscalls __NR_SYSCALL_BASE+253, __NR_SYSCALL_BASE+254 and
>> __NR_SYSCALL_BASE+255.
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Piotr Isajew <pki at ex.com.pl>
>> To: lxc-users at lists.linuxcontainers.org
>> Cc:
>> Date: Fri, 3 Jan 2014 09:37:15 +0100
>> Subject: [lxc-users] lxc-start hangs with no output
>> Hi,
>>
>> I wanted do try out lxc on Slackware 14.1 64-bit. lxc-create
>> works without problems. I'm however unable to start a container.
>>
>> After I do i.e.:
>>
>> lxc-start -n vs0
>>
>> the command just hangs with no output, consuming all the CPU
>> resources and eventually eating up all the memory.
>>
>> I've spent last three days trying to get it work but I think I've
>> ran out of ideas.
>>
>>
>> log file contains:
>>
>> lxc-start 1388667324.768 INFO lxc_start_ui - using rcfile
>> /var/lib/lxc/vs0/config
>> lxc-start 1388667324.769 INFO lxc_apparmor - apparmor_load -
>> apparmor is disabled
>> lxc-start 1388667324.770 DEBUG lxc_conf - allocated pty
>> '/dev/pts/2' (5/6)
>> lxc-start 1388667324.771 DEBUG lxc_conf - allocated pty
>> '/dev/pts/3' (7/8)
>> lxc-start 1388667324.771 DEBUG lxc_conf - allocated pty
>> '/dev/pts/4' (9/10)
>> lxc-start 1388667324.771 DEBUG lxc_conf - allocated pty
>> '/dev/pts/5' (11/12)
>> lxc-start 1388667324.771 INFO lxc_conf - tty's configured
>> lxc-start 1388667324.771 DEBUG lxc_console - using
>> '/tmp/console.log' as console log
>> lxc-start 1388667324.771 DEBUG lxc_console - using '/dev/tty' as
>> console
>> lxc-start 1388667324.771 DEBUG lxc_start - sigchild handler set
>> lxc-start 1388667324.771 INFO lxc_start - 'vs0' is initialized
>> lxc-start 1388667324.777 DEBUG lxc_start - Not dropping
>> cap_sys_boot or watching utmp
>>
>> lxc-start 1388667324.777 INFO lxc_conf - opened
>> /var/lib/lxc/vs0/rootfs.hold as fd 20
>>
>> After I kill the lxc-start process there are many entries like
>> vs0-1234 in /cgroup/lxc
>>
>> My configuration is as follows:
>>
>> Linux kontrabanda 3.10.17 #4 SMP Thu Jan 2 19:49:59 CET 2014 x86_64
>> Intel(R) Atom(TM) CPU D425 @ 1.80GHz GenuineIntel GNU/Linux
>>
>>
>> # lxc-checkconfig
>> --- Namespaces ---
>> Namespaces: enabled
>> Utsname namespace: enabled
>> Ipc namespace: enabled
>> Pid namespace: enabled
>> User namespace: enabled
>> Network namespace: enabled
>> Multiple /dev/pts instances: enabled
>>
>> --- Control groups ---
>> Cgroup: enabled
>> Cgroup clone_children flag: enabled
>> Cgroup device: enabled
>> Cgroup sched: enabled
>> Cgroup cpu account: enabled
>> Cgroup memory controller: enabled
>> Cgroup cpuset: enabled
>>
>> --- Misc ---
>> Veth pair device: enabled
>> Macvlan: enabled
>> Vlan: enabled
>> File capabilities: enabled
>>
>>
>> # cat /var/lib/lxc/vs0/config
>> # Template used to create this container: slackware
>> # Template script checksum (SHA-1):
>> 54f35064852a068c7ed1d0ae5e4b3ac8200ac790
>>
>> lxc.network.type = empty
>>
>>
>> lxc.utsname = vs0
>>
>> lxc.mount = /var/lib/lxc/vs0/rootfs/etc/fstab
>>
>> lxc.tty = 4
>> lxc.pts = 1024
>> lxc.rootfs = /var/lib/lxc/vs0/rootfs
>>
>> lxc.cgroup.devices.deny = a
>> # /dev/null and zero
>> lxc.cgroup.devices.allow = c 1:3 rwm
>> lxc.cgroup.devices.allow = c 1:5 rwm
>> # consoles
>> lxc.cgroup.devices.allow = c 5:1 rwm
>> lxc.cgroup.devices.allow = c 5:0 rwm
>> lxc.cgroup.devices.allow = c 4:0 rwm
>> lxc.cgroup.devices.allow = c 4:1 rwm
>> # /dev/{,u}random
>> lxc.cgroup.devices.allow = c 1:9 rwm
>> lxc.cgroup.devices.allow = c 1:8 rwm
>> lxc.cgroup.devices.allow = c 136:* rwm
>> lxc.cgroup.devices.allow = c 5:2 rwm
>> # rtc
>> lxc.cgroup.devices.allow = c 254:0 rwm
>>
>> # we don't trust root user in the container, better safe than sorry.
>> # comment out only if you know what you're doing.
>> lxc.cap.drop = sys_module mknod
>> lxc.cap.drop = mac_override kill sys_time
>> lxc.cap.drop = setfcap setpcap sys_boot
>>
>> # if you want to be even more restrictive with your container's root
>> # user comment the three lines above and uncomment the following one
>> # lxc.cap.drop=sys_admin
>>
>>
>> # cat /var/lib/lxc/vs0/rootfs/etc/fstab
>> lxcpts /var/lib/lxc/vs0/rootfs/dev/pts devpts defaults,newinstance 0 0
>> none /var/lib/lxc/vs0/rootfs/proc proc defaults 0 0
>> none /var/lib/lxc/vs0/rootfs/sys sysfs defaults 0 0
>> none /dev/shm tmpfs defaults 0 0
>>
>>
>> # mount | grep cgroup
>> cgroup on /cgroup type cgroup (rw)
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Kevin Wilson <wkevils at gmail.com>
>> To: LXC users mailing-list <lxc-users at lists.linuxcontainers.org>
>> Cc:
>> Date: Fri, 3 Jan 2014 11:42:26 +0200
>> Subject: [lxc-users] Cannot stop busybox container
>> Hello, lxc-users,
>>
>> I work with latest lxc from git.
>> I created a busybox container (with -t busybox).
>>
>> I create a bridge on the host (virbr0).
>> When I start the busybox container, I see:
>>
>> udhcpc (v1.19.4) started
>> Sending discover...
>> Sending discover...
>> Sending discover...
>> ...
>> and many more "Sending discover..." messages.
>>
>> There is no DHCP server in the LAN.
>> I have two questions:
>> 1) Is it possible to configure the busybox container so that it will not
>> start that udhcpc daemon and/or that it will not try to send these
>> DHCP discover messages ? \
>> 2) I try to stop the busybox container (which is called busyboxCT) with
>> lxc-stop -n busyboxCT
>> and I wait over 10 minutes and it was not stopped, and the DHCP
>> messages were still sent out from it.
>> Is there a way to stop that container in such a case?
>>
>> regards,
>> Kevin
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Giuseppe Tofoni <gt0057 at gmail.com>
>> To: LXC users mailing-list <lxc-users at lists.linuxcontainers.org>
>> Cc:
>> Date: Fri, 3 Jan 2014 12:03:31 +0100
>> Subject: Re: [lxc-users] lxc-start hangs with no output
>> Hi, Piotr
>>
>> One possible solution is to not mount /cgroup in fstab on the host.
>>
>> My configuration:
>> Slackware 14.1
>> lxc version 0.9.0
>> kernel 3.12.5
>>
>> try it and good luck
>>
>> Giuseppe
>>
>>
>>
>> 2014/1/3 Piotr Isajew <pki at ex.com.pl>
>>
>>> Hi,
>>>
>>> I wanted do try out lxc on Slackware 14.1 64-bit. lxc-create
>>> works without problems. I'm however unable to start a container.
>>>
>>> After I do i.e.:
>>>
>>> lxc-start -n vs0
>>>
>>> the command just hangs with no output, consuming all the CPU
>>> resources and eventually eating up all the memory.
>>>
>>> I've spent last three days trying to get it work but I think I've
>>> ran out of ideas.
>>>
>>>
>>> log file contains:
>>>
>>> lxc-start 1388667324.768 INFO lxc_start_ui - using rcfile
>>> /var/lib/lxc/vs0/config
>>> lxc-start 1388667324.769 INFO lxc_apparmor - apparmor_load -
>>> apparmor is disabled
>>> lxc-start 1388667324.770 DEBUG lxc_conf - allocated pty
>>> '/dev/pts/2' (5/6)
>>> lxc-start 1388667324.771 DEBUG lxc_conf - allocated pty
>>> '/dev/pts/3' (7/8)
>>> lxc-start 1388667324.771 DEBUG lxc_conf - allocated pty
>>> '/dev/pts/4' (9/10)
>>> lxc-start 1388667324.771 DEBUG lxc_conf - allocated pty
>>> '/dev/pts/5' (11/12)
>>> lxc-start 1388667324.771 INFO lxc_conf - tty's configured
>>> lxc-start 1388667324.771 DEBUG lxc_console - using
>>> '/tmp/console.log' as console log
>>> lxc-start 1388667324.771 DEBUG lxc_console - using '/dev/tty'
>>> as console
>>> lxc-start 1388667324.771 DEBUG lxc_start - sigchild handler set
>>> lxc-start 1388667324.771 INFO lxc_start - 'vs0' is initialized
>>> lxc-start 1388667324.777 DEBUG lxc_start - Not dropping
>>> cap_sys_boot or watching utmp
>>>
>>> lxc-start 1388667324.777 INFO lxc_conf - opened
>>> /var/lib/lxc/vs0/rootfs.hold as fd 20
>>>
>>> After I kill the lxc-start process there are many entries like
>>> vs0-1234 in /cgroup/lxc
>>>
>>> My configuration is as follows:
>>>
>>> Linux kontrabanda 3.10.17 #4 SMP Thu Jan 2 19:49:59 CET 2014 x86_64
>>> Intel(R) Atom(TM) CPU D425 @ 1.80GHz GenuineIntel GNU/Linux
>>>
>>>
>>> # lxc-checkconfig
>>> --- Namespaces ---
>>> Namespaces: enabled
>>> Utsname namespace: enabled
>>> Ipc namespace: enabled
>>> Pid namespace: enabled
>>> User namespace: enabled
>>> Network namespace: enabled
>>> Multiple /dev/pts instances: enabled
>>>
>>> --- Control groups ---
>>> Cgroup: enabled
>>> Cgroup clone_children flag: enabled
>>> Cgroup device: enabled
>>> Cgroup sched: enabled
>>> Cgroup cpu account: enabled
>>> Cgroup memory controller: enabled
>>> Cgroup cpuset: enabled
>>>
>>> --- Misc ---
>>> Veth pair device: enabled
>>> Macvlan: enabled
>>> Vlan: enabled
>>> File capabilities: enabled
>>>
>>>
>>> # cat /var/lib/lxc/vs0/config
>>> # Template used to create this container: slackware
>>> # Template script checksum (SHA-1):
>>> 54f35064852a068c7ed1d0ae5e4b3ac8200ac790
>>>
>>> lxc.network.type = empty
>>>
>>>
>>> lxc.utsname = vs0
>>>
>>> lxc.mount = /var/lib/lxc/vs0/rootfs/etc/fstab
>>>
>>> lxc.tty = 4
>>> lxc.pts = 1024
>>> lxc.rootfs = /var/lib/lxc/vs0/rootfs
>>>
>>> lxc.cgroup.devices.deny = a
>>> # /dev/null and zero
>>> lxc.cgroup.devices.allow = c 1:3 rwm
>>> lxc.cgroup.devices.allow = c 1:5 rwm
>>> # consoles
>>> lxc.cgroup.devices.allow = c 5:1 rwm
>>> lxc.cgroup.devices.allow = c 5:0 rwm
>>> lxc.cgroup.devices.allow = c 4:0 rwm
>>> lxc.cgroup.devices.allow = c 4:1 rwm
>>> # /dev/{,u}random
>>> lxc.cgroup.devices.allow = c 1:9 rwm
>>> lxc.cgroup.devices.allow = c 1:8 rwm
>>> lxc.cgroup.devices.allow = c 136:* rwm
>>> lxc.cgroup.devices.allow = c 5:2 rwm
>>> # rtc
>>> lxc.cgroup.devices.allow = c 254:0 rwm
>>>
>>> # we don't trust root user in the container, better safe than sorry.
>>> # comment out only if you know what you're doing.
>>> lxc.cap.drop = sys_module mknod
>>> lxc.cap.drop = mac_override kill sys_time
>>> lxc.cap.drop = setfcap setpcap sys_boot
>>>
>>> # if you want to be even more restrictive with your container's root
>>> # user comment the three lines above and uncomment the following one
>>> # lxc.cap.drop=sys_admin
>>>
>>>
>>> # cat /var/lib/lxc/vs0/rootfs/etc/fstab
>>> lxcpts /var/lib/lxc/vs0/rootfs/dev/pts devpts defaults,newinstance 0 0
>>> none /var/lib/lxc/vs0/rootfs/proc proc defaults 0 0
>>> none /var/lib/lxc/vs0/rootfs/sys sysfs defaults 0 0
>>> none /dev/shm tmpfs defaults 0 0
>>>
>>>
>>> # mount | grep cgroup
>>> cgroup on /cgroup type cgroup (rw)
>>> _______________________________________________
>>> lxc-users mailing list
>>> lxc-users at lists.linuxcontainers.org
>>> http://lists.linuxcontainers.org/listinfo/lxc-users
>>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Piotr Isajew <pki at ex.com.pl>
>> To: lxc-users at lists.linuxcontainers.org
>> Cc:
>> Date: Fri, 3 Jan 2014 12:31:05 +0100
>> Subject: Re: [lxc-users] lxc-start hangs with no output
>> On Fri, Jan 03, 2014 at 12:03:31PM +0100, Giuseppe Tofoni wrote:
>>
>> > One possible solution is to not mount /cgroup in fstab on the
>> > host.
>>
>> Thank you Giuseppe. Following your advice solved that problem.
>>
>> Have a nice day :)
>>
>> Piotr
>>
>>
>> _______________________________________________
>> lxc-users mailing list
>> lxc-users at lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20140107/5251af29/attachment-0001.html>
More information about the lxc-users
mailing list