https://bugzilla.redhat.com/show_bug.cgi?id=1185423
Bug ID: 1185423
Summary: MountFlags=private in docker.service prevents admin
from exposing new storage to docker
Product: Fedora
Version: 21
Component: docker-io
Assignee: lsm5(a)redhat.com
Reporter: lars(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: adimania(a)gmail.com, admiller(a)redhat.com,
golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.com,
jchaloup(a)redhat.com, jperrin(a)centos.org,
lsm5(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, miminar(a)redhat.com, s(a)shk.io,
thrcka(a)redhat.com, vbatts(a)redhat.com
Setting MountFlags=private in docker.service means that any storage mounted on
the host after starting Docker will be unavailable for docker containers. For
example, I wanted to expose a directory from a remote server to a Docker
container:
mkdir /data/content
mount remote-server:/vol/content /data/content
docker run -v /data/content:/content larsks/thttpd -d /content
This fails because Docker does not see the mount onto /data/content. It only
sees the content of the underlying directory, not the mounted filesystem.
I think we want MountFlags=slave instead, which would prevent mounts inside the
Docker mount namespace from propagating to the global namespace while still
allowing global mounts to be available to docker containers.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1184266
Bug ID: 1184266
Summary: missing debug info
Product: Fedora
Version: rawhide
Component: docker-io
Assignee: lsm5(a)redhat.com
Reporter: jan.kratochvil(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: adimania(a)gmail.com, admiller(a)redhat.com,
golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.com,
jchaloup(a)redhat.com, jperrin(a)centos.org,
lsm5(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, miminar(a)redhat.com, s(a)shk.io,
thrcka(a)redhat.com, vbatts(a)redhat.com
Created attachment 982069
--> https://bugzilla.redhat.com/attachment.cgi?id=982069&action=edit
docker-io.spec patch
Description of problem:
Current docker-io.rpm is not debuggable at all.
With the patch below the debugging gets significantly improved.
Further fixes will be needed.
Version-Release number of selected component (if applicable):
docker-io-1.4.1-7.fc22
How reproducible:
Always.
Steps to Reproduce:
gdb -ex 'catch fork' -ex r -ex 'thread apply all bt' --args docker -d
Actual results:
------------------------------------------------------------------------------
Catchpoint 1 (forked process 8419), 0x00000000005eb5c5 in syscall.RawSyscall6
()
Thread 4 (Thread 0x7fffeffff700 (LWP 8418)):
#0 0x0000000000448b23 in runtime.futex ()
#1 0x0000000000438f67 in runtime.futexsleep ()
#2 0x000000c208020b58 in ?? ()
#3 0x0000000000000000 in ?? ()
Thread 3 (Thread 0x7ffff4f32700 (LWP 8417)):
#0 0x0000000000448b23 in runtime.futex ()
#1 0x0000000000438f67 in runtime.futexsleep ()
#2 0x0000000001100900 in ?? ()
#3 0x0000000000000000 in ?? ()
Thread 2 (Thread 0x7ffff5733700 (LWP 8416)):
#0 0x000000000044885d in runtime.usleep ()
#1 0x0000000000000000 in ?? ()
Thread 1 (Thread 0x7ffff7fbb800 (LWP 8412)):
#0 0x00000000005eb5c5 in syscall.RawSyscall6 ()
#1 0x00000000005dd7ee in syscall.forkAndExecInChild ()
#2 0x0000000000000038 in ?? ()
#3 0x0000000000000011 in ?? ()
#4 0x0000000000000000 in ?? ()
------------------------------------------------------------------------------
Expected results:
------------------------------------------------------------------------------
Catchpoint 1 (forked process 8389), syscall.RawSyscall6 () at
/usr/lib/golang/src/syscall/asm_linux_amd64.s:101
101 CMPQ AX, $0xfffffffffffff001
Thread 5 (Thread 0x7fffef7fe700 (LWP 8388)):
#0 runtime.futex () at /usr/lib/golang/src/runtime/sys_linux_amd64.s:278
#1 0x0000000000438f67 in runtime.futexsleep () at
/usr/lib/golang/src/runtime/os_linux.c:49
#2 0x0000000000415ede in runtime.notesleep (n=0xc208020ed8) at
/usr/lib/golang/src/runtime/lock_futex.go:145
#3 0x000000000043c439 in stopm () at /usr/lib/golang/src/runtime/proc.c:1178
#4 0x000000000043cb38 in startlockedm () at
/usr/lib/golang/src/runtime/proc.c:1329
#5 0x000000000043d67a in schedule () at
/usr/lib/golang/src/runtime/proc.c:1582
#6 0x000000000043db3e in goexit0 () at /usr/lib/golang/src/runtime/proc.c:1717
#7 0x0000000000445d2a in runtime.mcall () at
/usr/lib/golang/src/runtime/asm_amd64.s:186
#8 0x000000c208012000 in ?? ()
#9 0x000000000043bbd4 in runtime.mstart () at
/usr/lib/golang/src/runtime/proc.c:836
#10 0x0000000000404533 in crosscall_amd64 () at
/builddir/build/BUILD/go/src/runtime/cgo/gcc_amd64.S:35
#11 0x0000000000000010 in ?? ()
#12 0x00007fffef7fe9c0 in ?? ()
#13 0x00007fffffffdc3f in ?? ()
#14 0x0000000000000001 in ?? ()
#15 0x000000c2080a27e0 in ?? ()
#16 0x000000000043bb30 in runtime.starttheworld () at
/usr/lib/golang/src/runtime/proc.c:761
#17 0x00007fffef7fe700 in ?? ()
#18 0xe1840af9c5b45b6d in ?? ()
#19 0x0000000000000001 in ?? ()
#20 0x00007fffffffdc3f in ?? ()
#21 0x00007fffef7fe9c0 in ?? ()
#22 0x0000000000000010 in ?? ()
#23 0x1e7bd40679745b6d in ?? ()
#24 0x1e7be5e649ee5b6d in ?? ()
#25 0x0000000000000000 in ?? ()
Thread 4 (Thread 0x7fffeffff700 (LWP 8387)):
#0 runtime.futex () at /usr/lib/golang/src/runtime/sys_linux_amd64.s:278
#1 0x0000000000438f67 in runtime.futexsleep () at
/usr/lib/golang/src/runtime/os_linux.c:49
#2 0x0000000000415ede in runtime.notesleep (n=0xc208020b58) at
/usr/lib/golang/src/runtime/lock_futex.go:145
#3 0x000000000043c439 in stopm () at /usr/lib/golang/src/runtime/proc.c:1178
#4 0x000000000043cb38 in startlockedm () at
/usr/lib/golang/src/runtime/proc.c:1329
#5 0x000000000043d67a in schedule () at
/usr/lib/golang/src/runtime/proc.c:1582
#6 0x000000000043d8d3 in runtime.park_m () at
/usr/lib/golang/src/runtime/proc.c:1654
#7 0x0000000000445d2a in runtime.mcall () at
/usr/lib/golang/src/runtime/asm_amd64.s:186
#8 0x000000c208012000 in ?? ()
#9 0x000000000043bbd4 in runtime.mstart () at
/usr/lib/golang/src/runtime/proc.c:836
#10 0x0000000000404533 in crosscall_amd64 () at
/builddir/build/BUILD/go/src/runtime/cgo/gcc_amd64.S:35
#11 0x0000000000000000 in ?? ()
Thread 3 (Thread 0x7ffff4f32700 (LWP 8386)):
#0 runtime.futex () at /usr/lib/golang/src/runtime/sys_linux_amd64.s:278
#1 0x0000000000438f67 in runtime.futexsleep () at
/usr/lib/golang/src/runtime/os_linux.c:49
#2 0x0000000000415f8d in runtime.notetsleep_internal (n=0x1102900
<runtime.sig>, ns=-1, ~r2=false) at
/usr/lib/golang/src/runtime/lock_futex.go:157
#3 0x00000000004161da in runtime.notetsleepg (n=0x1102900 <runtime.sig>,
ns=-1, ~r2=true) at /usr/lib/golang/src/runtime/lock_futex.go:202
#4 0x0000000000422f25 in runtime.signal_recv (~r0=0) at
/usr/lib/golang/src/runtime/sigqueue.go:109
#5 0x00000000007a363f in os/signal.loop () at
/usr/lib/golang/src/os/signal/signal_unix.go:21
#6 0x0000000000448231 in runtime.goexit () at
/usr/lib/golang/src/runtime/asm_amd64.s:2232
#7 0x0000000000000000 in ?? ()
Thread 2 (Thread 0x7ffff5733700 (LWP 8385)):
#0 runtime.usleep () at /usr/lib/golang/src/runtime/sys_linux_amd64.s:82
#1 0x000000000044056b in sysmon () at /usr/lib/golang/src/runtime/proc.c:2892
#2 0x000000000043bcc1 in mstart () at /usr/lib/golang/src/runtime/proc.c:859
#3 0x000000000043bbd4 in runtime.mstart () at
/usr/lib/golang/src/runtime/proc.c:836
#4 0x0000000000404533 in crosscall_amd64 () at
/builddir/build/BUILD/go/src/runtime/cgo/gcc_amd64.S:35
#5 0x0000000000000000 in ?? ()
Thread 1 (Thread 0x7ffff7fbb800 (LWP 8381)):
#0 syscall.RawSyscall6 () at /usr/lib/golang/src/syscall/asm_linux_amd64.s:101
#1 0x00000000005dd7ee in syscall.forkAndExecInChild (argv0=0xc20810e500
"/usr/sbin/iptables", argv=..., envv=..., chroot=0x0, dir=0x0,
attr=0xc2080e7b40, sys=0x10f81c0 <syscall.zeroSysProcAttr>, pipe=7,
pid=216172782113783818, err=...) at
/usr/lib/golang/src/syscall/exec_linux.go:85
#2 0x00000000005df474 in syscall.forkExec (argv0=..., argv=...,
attr=0xc2080e7b40, pid=10011360, err=...) at
/usr/lib/golang/src/syscall/exec_unix.go:191
#3 0x00000000005df842 in syscall.StartProcess (argv0=..., argv=...,
attr=0xc2080e7b40, pid=2, handle=4, err=...) at
/usr/lib/golang/src/syscall/exec_unix.go:238
#4 0x0000000000542ddb in os.startProcess (name=..., argv=...,
attr=0xc20802fc70, p=0xace2c0, err=...) at
/usr/lib/golang/src/os/exec_posix.go:45
#5 0x00000000005415f2 in os.StartProcess (name=..., argv=...,
attr=0xc20802fc70, ~r3=0x2, ~r4=...) at /usr/lib/golang/src/os/doc.go:24
#6 0x000000000066db0e in os/exec.(*Cmd).Start (~r0=...) at
/usr/lib/golang/src/os/exec/exec.go:316
#7 0x000000000066d18a in os/exec.(*Cmd).Run (c=0xc208081680, ~r0=...) at
/usr/lib/golang/src/os/exec/exec.go:243
#8 0x0000000000892da2 in github.com/docker/docker/pkg/iptables.init·1 () at
/home/jkratoch/redhat/fedora/docker-io/master/docker-1.4.1/_build/src/github.com/docker/docker/pkg/iptables/iptables.go:43
#9 0x0000000000895b35 in github.com/docker/docker/pkg/iptables.init () at
/home/jkratoch/redhat/fedora/docker-io/master/docker-1.4.1/_build/src/github.com/docker/docker/pkg/iptables/iptables.go:201
#10 0x00000000006b81d9 in
github.com/docker/docker/daemon/networkdriver/bridge.init () at
/home/jkratoch/redhat/fedora/docker-io/master/docker-1.4.1/_build/src/github.com/docker/docker/daemon/networkdriver/bridge/driver.go:536
#11 0x00000000004a2bd2 in github.com/docker/docker/daemon.init () at
/home/jkratoch/redhat/fedora/docker-io/master/docker-1.4.1/_build/src/github.com/docker/docker/daemon/wait.go:20
#12 0x000000000040935e in main.init () at
/home/jkratoch/redhat/fedora/docker-io/master/docker-1.4.1/docker/log.go:12
#13 0x000000000041ec94 in runtime.main () at
/usr/lib/golang/src/runtime/proc.go:58
#14 0x0000000000448231 in runtime.goexit () at
/usr/lib/golang/src/runtime/asm_amd64.s:2232
#15 0x0000000000000000 in ?? ()
------------------------------------------------------------------------------
Additional info:
There was Bug 1017186 Comment 3 but I do not see it would not be working:
# This also adds -w, to disable building with debugging in the executable which
isn't working with debuginfo anyway.
--
You are receiving this mail because:
You are on the CC list for the bug.
Hi all,
I propose to prefer using vendored/bundled golang deps and use rpm dependencies only
as a last resort for golang packages.
Short story long: quite a few golang packages like docker, kubernetes and (hopefully soon)
rocket provide a dir like 'vendor/' or 'Godeps/' which includes the golang
dependencies used, thus making rpm dependencies redundant IMO. Using the
bundled sources makes building packages a lot more convenient than depending
on rpms.
I'm aware that the dependencies are different upstreams but since those are
bundled along with the main tool, perhaps we can relax that restriction.
As most of you may have already experienced, golang deps are a huge PITA to
update/use in docker/kube though props to jchaloup on making golang packaging very easy:
https://github.com/ingvagabund/GolangPackageGenerator
All that said, we could still continue to package golang repos in case
someone needs it for something.
I was hoping we could yay or nay on this and
also perhaps modify the golang packaging draft if everyone agrees.
https://fedoraproject.org/wiki/PackagingDrafts/Go#Dependencies
Comments?
PS: I'm doing this already for daily rebuilds of docker master branch on
fedora rawhide starting today.
--
Lokesh
Freenode, OFTC: lsm5
GPG: 0xC7C3A0DD