June 2014 - golang - Fedora mailing-lists

[Bug 1087700] New: lost signals when sending lots of signals using --sig-proxy to docker
by Red Hat Bugzilla 29 May '15

29 May '15

https://bugzilla.redhat.com/show_bug.cgi?id=1087700 Bug ID: 1087700 Summary: lost signals when sending lots of signals using --sig-proxy to docker Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: ldoktor(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com Description of problem: When I send lots of signals to the running docker with --sig-proxy (actual kill signals, not `docker kill`), most of them got lost. Version-Release number of selected component (if applicable): docker-io-0.9.1-1.fc21.x86_64 How reproducible: always Steps to Reproduce: 1. /usr/bin/docker -D run --tty=false --rm -i --name test_eoly localhost:5000/ldoktor/fedora:latest bash -c 'for NUM in `seq 1 64`; do trap "echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done' 2. ps ax |grep docker 3. for AAA in `seq 1 32`; do [ $AAA -ne 9 ] && [ $AAA -ne 20 ] && [ $AAA -ne 19 ] && kill -s $AAA $PID; done Actual results: Output of the docker is: Received 1, ignoring... Received 2, ignoring... Expected results: Messages for all of the `Received $NUM, ignoring...` printed (order doesn't matter) Additional info: Skipping 9, 19, 20 as they are a bit too special.. -- You are receiving this mail because: You are on the CC list for the bug.

1 15

[Bug 1093000] New: Unable to save an image to a tar archive
by Red Hat Bugzilla 29 May '15

29 May '15

https://bugzilla.redhat.com/show_bug.cgi?id=1093000 Bug ID: 1093000 Summary: Unable to save an image to a tar archive Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: lslebodn(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com Description of problem: I tried to dump content of docker image to a tarball with command "docker save" It failed with error message "no space left on device" Version-Release number of selected component (if applicable): I was able to reproduce problem with docker-io from stable repository and with docker-io from updates-testing [root@vm-169 docker]# rpm -q docker-io docker-io-0.9.1-1.fc20.x86_64 or docker-io-0.10.0-2.fc20.x86_64 How reproducible: Allways Steps to Reproduce: 1. Create big docker image (e.g. 1.8 GiB) [root@vm-169 docker-freeipa]# docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE big_image latest b366efe500de 57 minutes ago 1.778 GB fedora 20 b7de3133ff98 5 days ago 372.7 MB 2. save docker image to tarball [root@vm-169 docker]# docker save big_image > big_image.tar Actual results: [root@vm-169 docker]# docker save big_image > big_image.tar 2014/04/30 12:39:38 Error: write /docker-export-085323451/934d868afd0a79629df2cad704cbc1ed9344654625569263a630933d2785de57/layer.tar: no space left on device [root@vm-169 docker]# file big_image.tar big_image.tar: empty [root@vm-169 docker]# ls -l big_image.tar -rw-r--r--. 1 root root 0 Apr 30 13:41 big_image.tar Expected results: File big_image.tar should not be empty and should contain data from docker image with name big_image Additional info: Directory /tmp should be used for creating small temporary files, because it is mounted on tmpfs. I think it would be better to use /var/tmp in this case. -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 1033604] New: Unable to start systemd service in Docker container
by Red Hat Bugzilla 19 May '15

19 May '15

https://bugzilla.redhat.com/show_bug.cgi?id=1033604 Bug ID: 1033604 Summary: Unable to start systemd service in Docker container Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: mfojtik(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, vbatts(a)redhat.com Description of problem: Using Dockerfile like this: FROM mattdm/fedora:latest RUN yum update -y RUN yum install -y redis RUN systemctl enable redis.service RUN systemctl start redis.service EXPOSE 6379 ENTRYPOINT ["/usr/bin/redis-cli"] The step 'systemctl start redis.service' failed with this error message: Failed to get D-Bus connection: No connection to service manager. Version-Release number of selected component (if applicable): Name : docker-io Arch : x86_64 Version : 0.7 Release : 0.17.rc6.fc20 Steps to Reproduce: 1. Save the above Dockerfile 2. Run: docker build -t test/redis . 3. The build fill faile on systemctl start. Actual results: The service failed to start due to D-BUS connection. Expected results: The service should be started? Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 33

[Bug 1092136] New: Docker commands pause streaming audio
by Red Hat Bugzilla 28 Apr '15

28 Apr '15

https://bugzilla.redhat.com/show_bug.cgi?id=1092136 Bug ID: 1092136 Summary: Docker commands pause streaming audio Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: mdavis(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com Description of problem: Execution of docker commands cause streaming audio to pause briefly (3-4 seconds) Version-Release number of selected component (if applicable): [root@dhcp81-173 ~]# rpm -q docker-io firefox flash-plugin docker-io-0.9.1-1.fc20.x86_64 firefox-28.0-3.fc20.x86_64 flash-plugin-11.2.202.350-release.x86_64 [root@dhcp81-173 ~]# uname -s -r -v -m Linux 3.13.10-200.fc20.x86_64 #1 SMP Mon Apr 14 20:34:16 UTC 2014 x86_64 How reproducible: Nearly every docker command does this. Steps to Reproduce: 1. Start up firefox and start listening to a streaming audio service (I reproduced it on spotify.com, using the spotify web player) 2. Run a docker command. For example... [root@dhcp81-173 ~]# docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE 10.3.76.138:5000/rhel6-base latest 60f3b7e9ba33 6 weeks ago 1.437 GB rhel6-base latest 60f3b7e9ba33 6 weeks ago 1.437 GB 10.3.76.138:5000/rhel7b-base latest b96a0bc033bb 8 weeks ago 827.9 MB fedora rawhide 0d20aec6529d 12 weeks ago 387 MB fedora 20 58394af37342 12 weeks ago 385.5 MB fedora heisenbug 58394af37342 12 weeks ago 385.5 MB fedora latest 58394af37342 12 weeks ago 385.5 MB busybox latest 769b9341d937 12 weeks ago 2.489 MB [root@dhcp81-173 ~]# docker run 0d2 id uid=0(root) gid=0(root) groups=0(root) [root@dhcp81-173 ~]# Actual results: Currently playing audio paused for 3 seconds after running the 'id' command. Expected results: Uninterrupted audio playing Additional info: I'm running Fedora 20 XFCE build. -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1046717] New: Cancel run or pull operation doesn't actually stop the ongoing task
by Red Hat Bugzilla 15 Apr '15

15 Apr '15

https://bugzilla.redhat.com/show_bug.cgi?id=1046717 Bug ID: 1046717 Summary: Cancel run or pull operation doesn't actually stop the ongoing task Product: Fedora Version: 20 Component: docker-io Severity: medium Assignee: lsm5(a)redhat.com Reporter: baptiste.millemathias(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com Description of problem: I've downloaded a docker image using "docker pull bradrydzewski/mongodb:2.4" and when I wanted to run it I did a "docker run bradrydzewski/mongodb" as the image name was named like that, and I saw docker pulling another image (the size was different), so I hit Ctrl+C thinking to going kill the operation. However a ps fax showed me dockerd was still downloading something, certainly image bradrydzewski/mongodb Version-Release number of selected component (if applicable): docker-io-0.7.0-14.fc20.x86_64 How reproducible: 100 % Steps to Reproduce: 1. docker pull bradrydzewski/mongodb:2.4 (let the complete operation happens) 2. docker run bradrydzewski/mongodb, and hit ctrl+c after few seconds Actual results: Dockerd still download image Expected results: docker client should ask Dockerd to cancel the download of the image -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1087704] New: repetition of signal 21 with --sig-proxy and SIGSTOP of docker
by Red Hat Bugzilla 15 Apr '15

15 Apr '15

https://bugzilla.redhat.com/show_bug.cgi?id=1087704 Bug ID: 1087704 Summary: repetition of signal 21 with --sig-proxy and SIGSTOP of docker Product: Fedora Version: 20 Component: docker-io Severity: low Assignee: lsm5(a)redhat.com Reporter: ldoktor(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com Description of problem: I noticed weird reaction to SIGSTOP signal. When you start container with --sig-proxy, ignore all signals in container and from OS use kill -SIGSTOP to the `docker run` process, it's put into background. (so far correct behavior) Than when you use kill -SIGCONT, it's resumed (still in background) and it's continuing to send signal 21 to the container (100% CPU utilization). This disappears once you attach the process with fg. Version-Release number of selected component (if applicable): docker-io-0.9.1-1.fc21.x86_64 How reproducible: always Steps to Reproduce: 1. /usr/bin/docker -D run --tty=false --rm -i --name test_eoly localhost:5000/ldoktor/fedora:latest bash -c 'for NUM in `seq 1 64`; do trap "echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done' 2. ps ax |grep docker 3. kill -SIGSTOP $PID 4. kill -SIGCONT $PID Actual results: [1]+ Pozastavena /usr/bin/docker -D run --tty=false --rm -i --name test_eoly localhost:5000/ldoktor/fedora:latest bash -c 'for NUM in `seq 1 64`; do trap "echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done' [root@t530 ~]# Received 21, ignoring... Received 21, ignoring... Received 21, ignoring... Received 21, ignoring... Received 21, ignoring... Received 21, ignoring... ... (100% CPU utilization, when you use fg it stops and you can use the container again...) Expected results: [1]+ Pozastavena /usr/bin/docker -D run --tty=false --rm -i --name test_eoly localhost:5000/ldoktor/fedora:latest bash -c 'for NUM in `seq 1 64`; do trap "echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done' [root@t530 ~]# Received 21, ignoring... Additional info: I'm not definitely sure if this is really required as it's not a common usage. But as there is no way to detach the process apart from kill -SIGSTOP people might use it and get to this problem... -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Bug 1087720] New: signal 27 (SIGPROF) not passed to container using --sig-proxy
by Red Hat Bugzilla 15 Apr '15

15 Apr '15

https://bugzilla.redhat.com/show_bug.cgi?id=1087720 Bug ID: 1087720 Summary: signal 27 (SIGPROF) not passed to container using --sig-proxy Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: ldoktor(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com Description of problem: When I send signal 27 to the docker process, which is running with --sig-proxy=true, it's not forwarded. Other signals are... Version-Release number of selected component (if applicable): docker-io-0.9.1-1.fc21.x86_64 How reproducible: always Steps to Reproduce: 1. /usr/bin/docker -D run --tty=false --rm -i --name test_eoly localhost:5000/ldoktor/fedora:latest bash -c 'for NUM in `seq 1 64`; do trap "echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done' 2. ps ax |grep docker 3. kill -27 $PID Actual results: nothing Expected results: Received 27, ignoring... Additional info: When you send any other signal (apart from 19 or 9) it works fine. -- You are receiving this mail because: You are on the CC list for the bug.

1 17

[Bug 1029587] New: upgrade to go1.2 (once it is available)
by Red Hat Bugzilla 19 Feb '15

19 Feb '15

https://bugzilla.redhat.com/show_bug.cgi?id=1029587 Bug ID: 1029587 Summary: upgrade to go1.2 (once it is available) Product: Fedora Version: rawhide Component: golang Severity: low Assignee: adam(a)spicenitz.org Reporter: vbatts(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: adam(a)spicenitz.org, admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lemenkov(a)gmail.com, lsm5(a)redhat.com, renich(a)woralelandia.com, vbatts(a)redhat.com What steps will reproduce the problem? If possible, include a link to a program on play.golang.org. 1. export GOPATH=$(mktemp -d) 2. go get code.google.com/p/go.tools/cmd/oracle 3. What is the expected output? What do you see instead? /tmp/tmp.cjYFzAeLWC/src/code.google.com/p/go.tools/importer/source.go:434: n.Lparen undefined (type *ast.TypeAssertExpr has no field or method Lparen) /tmp/tmp.cjYFzAeLWC/src/code.google.com/p/go.tools/importer/source.go:435: n.Lparen undefined (type *ast.TypeAssertExpr has no field or method Lparen) /tmp/tmp.cjYFzAeLWC/src/code.google.com/p/go.tools/importer/source.go:436: n.Rparen undefined (type *ast.TypeAssertExpr has no field or method Rparen) Which compiler are you using (5g, 6g, 8g, gccgo)? 6g Which operating system are you using? Red Hat Enterprise Linux Workstation release 6.4 (Santiago) Which version are you using? go version go1.1.2 linux/amd64 (golang-1.1.2-4.el6.x86_64) Please provide any additional information below. I tested against the tip of their repo (future version 1.2) (go version devel +39c724dd7f25 Tue Nov 12 09:28:07 2013 +1100 linux/amd64) and code.google.com/p/go.tools/cmd/oracle and code.google.com/p/go.tools/cmd/ssadump build just fine -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1099074] New: Processing Dependency: golang-docs = 1.1-2.fc19 for package: golang-godoc-1.1-2.fc19.x86_64
by Red Hat Bugzilla 17 Feb '15

17 Feb '15

https://bugzilla.redhat.com/show_bug.cgi?id=1099074 Bug ID: 1099074 Summary: Processing Dependency: golang-docs = 1.1-2.fc19 for package: golang-godoc-1.1-2.fc19.x86_64 Product: Fedora Version: 19 Component: golang Severity: high Assignee: adam(a)spicenitz.org Reporter: dridi.boukelmoune(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: adam(a)spicenitz.org, admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lemenkov(a)gmail.com, lsm5(a)redhat.com, renich(a)woralelandia.com, s(a)shk.io, vbatts(a)redhat.com Description of problem: I'm trying to install the golang-godoc package but it fails. It's looking for golang-docs which is provided by golang, but the required version doesn't match. Version-Release number of selected component (if applicable): golang-1.2.1-1.fc19.x86_64 golang-godoc-1.1-2.fc19.x86_64 How reproducible: always Steps to Reproduce: 1. sudo yum install golang 2. sudo yum install golang-godoc Actual results: Resolving Dependencies --> Running transaction check ---> Package golang-godoc.x86_64 0:1.1-2.fc19 will be installed --> Processing Dependency: golang-docs = 1.1-2.fc19 for package: golang-godoc-1.1-2.fc19.x86_64 Package golang-docs-1.1-2.fc19.noarch is obsoleted by golang-1.2.1-1.fc19.x86_64 which is already installed --> Processing Dependency: golang(x86-64) = 1.1-2.fc19 for package: golang-godoc-1.1-2.fc19.x86_64 --> Finished Dependency Resolution Error: Package: golang-godoc-1.1-2.fc19.x86_64 (fedora) Requires: golang(x86-64) = 1.1-2.fc19 Installed: golang-1.2.1-1.fc19.x86_64 (@updates) golang(x86-64) = 1.2.1-1.fc19 Available: golang-1.1-2.fc19.x86_64 (fedora) golang(x86-64) = 1.1-2.fc19 Error: Package: golang-godoc-1.1-2.fc19.x86_64 (fedora) Requires: golang-docs = 1.1-2.fc19 Available: golang-docs-1.1-2.fc19.noarch (fedora) golang-docs = 1.1-2.fc19 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Expected results: Is this ok [y/d/N]: Additional info: I couldn't find golang-godoc in pkgdb2, so I'm filing against golang. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1056185] New: go test code.google.com/p/go.net/ipv6 test fails
by Red Hat Bugzilla 26 Jan '15

26 Jan '15

https://bugzilla.redhat.com/show_bug.cgi?id=1056185 Bug ID: 1056185 Summary: go test code.google.com/p/go.net/ipv6 test fails Product: Fedora EPEL Version: el6 Component: golang-googlecode-net Assignee: lsm5(a)redhat.com Reporter: tis(a)foobar.fi QA Contact: extras-qa(a)fedoraproject.org CC: golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, vbatts(a)redhat.com Description of problem: %check fails if machine you build this package on has ipv6 connectivity. + go test code.google.com/p/go.net/ipv6 --- FAIL: TestConnInitiatorPathMTU (0.00 seconds) sockopt_test.go:58: ipv6.Conn.PathMTU failed: getsockopt: protocol not available --- FAIL: TestConnResponderPathMTU (0.00 seconds) sockopt_test.go:91: ipv6.Conn.PathMTU failed: getsockopt: protocol not available --- FAIL: TestPacketConnReadWriteUnicastUDP (0.00 seconds) unicast_test.go:120: ipv6.PacketConn.SetControlMessage failed: setsockopt: protocol not available FAIL FAIL code.google.com/p/go.net/ipv6 0.041s RPM build errors: error: Bad exit status from /var/tmp/rpm-tmp.DbihRB (%check) I guess package is broken for ipv6. -- You are receiving this mail because: You are on the CC list for the bug.

1 34

[Bug 1101123] New: docker package binary conflicts with docker-io
by Red Hat Bugzilla 05 Jan '15

05 Jan '15

https://bugzilla.redhat.com/show_bug.cgi?id=1101123 Bug ID: 1101123 Summary: docker package binary conflicts with docker-io Product: Fedora Version: 20 Component: docker-io Severity: medium Assignee: lsm5(a)redhat.com Reporter: dmcf(a)dcorking.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com Description of problem: There is a file name conflict for /usr/bin/docker between 2 Fedora 20 packages. Version-Release number of selected component (if applicable): docker-1.5-10.fc20.x86_64 (f20 updates, a dockapp that provides a system tray for WindowMaker, XFCE etc.) docker-io-0.11.1-1.fc20.x86_64.rpm (f20 updates, a new Linux containerization app that has proven very popular) How reproducible: Consistent. Steps to Reproduce: 1. sudo yum install docker 2. sudo yum install docker-io Actual results: Transaction check error: file /usr/bin/docker from install of docker-io-0.11.1-1.fc20.x86_64 conflicts with file from package docker-1.5-10.fc20.x86_64 Expected results: All packages in F20 should be able to co-exist unless a conflict is documented in the RPM file. Since the conflict is only file naming, one of these packages could be patched to allow it to co-exist with the other. Additional info: Possible workaround that keeps docker working for me follows. (It allows docker-io to install, but I am not sure if docker-io is fully functioning.) #!/bin/bash sudo mv /usr/bin/docker /usr/bin/wmdocker # user must change dock icons that link to docker to point to wmdocker sudo yum install docker-io --downloadonly cd /var/cache/yum/x86_64/20/updates/packages/ sudo rpm -Uvf --force docker-io-0.11.1-1.fc20.x86_64.rpm The conflict probably also exists in rawhide. (unverified) The upstream binary in both packages is 'docker'. Debian/Ubuntu rename their binary to 'docker-io' to deal with the conflict. There is a plan to replace the 'docker' package with a renamed 'wmdocker' package in F21. (Bug # 1043676). However, that will take until F23 release to complete the Obsoletes/Expires process. In the meantime, any user with docker from F20 or rawhide will be unable to install docker-io, unless they use the workaround. Related issues: * https://fedorahosted.org/fpc/ticket/341 "How to replace "docker" package with an entirely different package of the same name?" * https://bugzilla.redhat.com/show_bug.cgi?id=1043676 "drop docker from rawhide (or redirect to wmdocker)" -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1106237] New: etcd: FTBFS in rawhide
by Red Hat Bugzilla 19 Dec '14

19 Dec '14

https://bugzilla.redhat.com/show_bug.cgi?id=1106237 Bug ID: 1106237 Summary: etcd: FTBFS in rawhide Product: Fedora Version: rawhide Component: etcd Assignee: lacypret(a)gmail.com Reporter: dennis(a)ausil.us QA Contact: extras-qa(a)fedoraproject.org CC: golang(a)lists.fedoraproject.org, lacypret(a)gmail.com, lemenkov(a)gmail.com Blocks: 1105908 Your package etcd failed to build from source in current rawhide. http://koji.fedoraproject.org/koji/taskinfo?taskID=6960841 For details on mass rebuild see https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1105908 [Bug 1105908] Fedora 21 Mass Rebuild FTBFS Tracker -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1114098] New: fedora 20: etcd broken on install, very out of date, and misconfigured.
by Red Hat Bugzilla 19 Dec '14

19 Dec '14

https://bugzilla.redhat.com/show_bug.cgi?id=1114098 Bug ID: 1114098 Summary: fedora 20: etcd broken on install, very out of date, and misconfigured. Product: Fedora Version: 20 Component: etcd Assignee: lacypret(a)gmail.com Reporter: bugs(a)jameskyle.org QA Contact: extras-qa(a)fedoraproject.org CC: golang(a)lists.fedoraproject.org, lacypret(a)gmail.com, lemenkov(a)gmail.com Description of problem: etcd service on fedora 20 only returns 404 page not found for all queries. Version-Release number of selected component (if applicable): Fedora 20, etcd 0.1.3 How reproducible: 100% Steps to Reproduce: 1. yum install etcd 2. systemctl start etcd 3. curl http://127.0.0.1:4001/v2/keys/foo -d "Bar" Actual results: 404 page not found Expected results: {"action":"set","node":{"key":"/message","value":"Hello","modifiedIndex":5,"createdIndex":5}} Additional info: The service was configured to use a systemd socket service, but (from the systemd debs) "etcd doesn't have socket activation". Even if I disabled the socket service and ran etcd 0.1.3 in the foreground with defaults, the same behavior was manifest. Installing the current 0.4.4 version of etcd produced the expected/desired behavior. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1108200] New: remove docker-io from epel7
by Red Hat Bugzilla 10 Nov '14

10 Nov '14

https://bugzilla.redhat.com/show_bug.cgi?id=1108200 Bug ID: 1108200 Summary: remove docker-io from epel7 Product: Fedora EPEL Version: epel7 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: lsm5(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com Description of problem: RHEL7 includes docker already so docker-io should be removed Version-Release number of selected component (if applicable): docker-io-1.0.0-1.el7 Additional info: el7 has already been retired from dist-git http://pkgs.fedoraproject.org/cgit/docker-io.git/tree/?h=epel7 and orphaned from pkgdb https://admin.fedoraproject.org/pkgdb/package/docker-io/ -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1047194] New: etcd-0.2.0 is available
by Red Hat Bugzilla 01 Nov '14

01 Nov '14

https://bugzilla.redhat.com/show_bug.cgi?id=1047194 Bug ID: 1047194 Summary: etcd-0.2.0 is available Product: Fedora Version: rawhide Component: etcd Keywords: FutureFeature, Triaged Assignee: lacypret(a)gmail.com Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: golang(a)lists.fedoraproject.org, lacypret(a)gmail.com, lemenkov(a)gmail.com, lsm5(a)redhat.com Latest upstream release: 0.2.0 Current version/release in Fedora Rawhide: 0.1.2-5.fc21 URL: https://api.github.com/repos/coreos/etcd/tags Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug.

1 32

[Bug 1113601] New: When kernel is installed as a dependency of autofs, various errors are shown
by Red Hat Bugzilla 28 Oct '14

28 Oct '14

https://bugzilla.redhat.com/show_bug.cgi?id=1113601 Bug ID: 1113601 Summary: When kernel is installed as a dependency of autofs, various errors are shown Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)switzerlandmail.ch Reporter: jpazdziora(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.com, lsm5(a)switzerlandmail.ch, mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com Description of problem: When kernel is installed as a dependency of autofs, various errors concerning /var are shown in posttrans. Version-Release number of selected component (if applicable): docker-io-1.0.0-4.fc20.x86_64 fedora:20 image as of today: 3f2fed40e4b0 How reproducible: Deterministic. Steps to Reproduce: 1. Have Dockerfile: FROM fedora:20 RUN yum install -y autofs 2. Run docker build -t autofs-test . Actual results: # docker build -t autofs-test . Sending build context to Docker daemon 2.56 kB Sending build context to Docker daemon Step 0 : FROM fedora:20 ---> 3f2fed40e4b0 Step 1 : RUN yum install -y autofs ---> Running in 9b0bbf2f654d http://mirrors.zimcom.net/pub/fedora/linux/updates/20/x86_64/repodata/repom…: [Errno 14] curl#7 - "Failed to connect to 2607:f550:100:33::23: Network is unreachable" Trying other mirror. Resolving Dependencies --> Running transaction check ---> Package autofs.x86_64 1:5.0.7-40.fc20 will be installed --> Processing Dependency: kernel >= 2.6.17 for package: 1:autofs-5.0.7-40.fc20.x86_64 --> Processing Dependency: libtirpc.so.1()(64bit) for package: 1:autofs-5.0.7-40.fc20.x86_64 --> Processing Dependency: libhesiod.so.0()(64bit) for package: 1:autofs-5.0.7-40.fc20.x86_64 --> Running transaction check ---> Package hesiod.x86_64 0:3.2.1-2.fc20 will be installed ---> Package kernel.x86_64 0:3.14.8-200.fc20 will be installed --> Processing Dependency: linux-firmware >= 20130724-29.git31f6b30 for package: kernel-3.14.8-200.fc20.x86_64 ---> Package libtirpc.x86_64 0:0.2.4-3.0.fc20 will be installed --> Running transaction check ---> Package linux-firmware.noarch 0:20140605-38.gita4f3bc03.fc20 will be installed --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: autofs x86_64 1:5.0.7-40.fc20 updates 524 k Installing for dependencies: hesiod x86_64 3.2.1-2.fc20 fedora 29 k kernel x86_64 3.14.8-200.fc20 updates 32 M libtirpc x86_64 0.2.4-3.0.fc20 updates 83 k linux-firmware noarch 20140605-38.gita4f3bc03.fc20 updates 21 M Transaction Summary ================================================================================ Install 1 Package (+4 Dependent packages) Total download size: 53 M Installed size: 192 M Downloading packages: Delta RPMs disabled because /usr/bin/applydeltarpm not installed. warning: /var/cache/yum/x86_64/20/fedora/packages/hesiod-3.2.1-2.fc20.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 246110c1: NOKEY Public key for hesiod-3.2.1-2.fc20.x86_64.rpm is not installed Public key for autofs-5.0.7-40.fc20.x86_64.rpm is not installed -------------------------------------------------------------------------------- Total 4.0 MB/s | 53 MB 00:13 Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-x86_64 Importing GPG key 0x246110C1: Userid : "Fedora (20) <fedora(a)fedoraproject.org>" Fingerprint: c7c9 a9c8 9153 f201 83ce 7cba 2eb1 61fa 2461 10c1 Package : fedora-release-20-3.noarch (@fedora-updates/$releasever) From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-x86_64 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : hesiod-3.2.1-2.fc20.x86_64 1/5 Installing : libtirpc-0.2.4-3.0.fc20.x86_64 2/5 Installing : linux-firmware-20140605-38.gita4f3bc03.fc20.noarch 3/5 Installing : kernel-3.14.8-200.fc20.x86_64 4/5 Installing : 1:autofs-5.0.7-40.fc20.x86_64 5/5 No '/dev/log' or 'logger' included for syslog logging mknod: '/var/tmp/initramfs.aD5A0T/dev/null': Operation not permitted mknod: '/var/tmp/initramfs.aD5A0T/dev/kmsg': Operation not permitted mknod: '/var/tmp/initramfs.aD5A0T/dev/console': Operation not permitted No '/dev/log' or 'logger' included for syslog logging mknod: '/var/tmp/initramfs.XRmzzi/dev/null': Operation not permitted mknod: '/var/tmp/initramfs.XRmzzi/dev/kmsg': Operation not permitted mknod: '/var/tmp/initramfs.XRmzzi/dev/console': Operation not permitted /usr/lib/kernel/install.d/51-dracut-rescue.install: line 59: /boot/loader/entries/5b2a1f96231d4de69964798a33d2add8-0-rescue.conf: No such file or directory warning: %posttrans(kernel-3.14.8-200.fc20.x86_64) scriptlet failed, exit status 1 Non-fatal POSTTRANS scriptlet failure in rpm package kernel-3.14.8-200.fc20.x86_64 Verifying : 1:autofs-5.0.7-40.fc20.x86_64 1/5 Verifying : linux-firmware-20140605-38.gita4f3bc03.fc20.noarch 2/5 Verifying : libtirpc-0.2.4-3.0.fc20.x86_64 3/5 Verifying : hesiod-3.2.1-2.fc20.x86_64 4/5 Verifying : kernel-3.14.8-200.fc20.x86_64 5/5 Installed: autofs.x86_64 1:5.0.7-40.fc20 Dependency Installed: hesiod.x86_64 0:3.2.1-2.fc20 kernel.x86_64 0:3.14.8-200.fc20 libtirpc.x86_64 0:0.2.4-3.0.fc20 linux-firmware.noarch 0:20140605-38.gita4f3bc03.fc20 Complete! ---> e11ccfbfb8a0 Removing intermediate container 9b0bbf2f654d Successfully built e11ccfbfb8a0 Expected results: Either kernel not pulled in, or no (or less) errors from posttrans. Additional info: Using docker-io component as a start of discussion about supporting autofs in Docker containers and if something can be changed in packaging of autofs or kernel or in the fedora:20 image to lower the posttrans noise. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1099206] New: timestamps of libraries and artifacts out of sync
by Red Hat Bugzilla 17 Oct '14

17 Oct '14

https://bugzilla.redhat.com/show_bug.cgi?id=1099206 Bug ID: 1099206 Summary: timestamps of libraries and artifacts out of sync Product: Fedora Version: rawhide Component: golang Assignee: adam(a)spicenitz.org Reporter: vbatts(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: adam(a)spicenitz.org, admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lemenkov(a)gmail.com, lsm5(a)redhat.com, renich(a)woralelandia.com, s(a)shk.io, vbatts(a)redhat.com Description of problem: https://gist.github.com/ncdc/1a6bcb988a700d52dfec Version-Release number of selected component (if applicable): 1.2.2-2 How reproducible: consisten Steps to Reproduce: 1. build something that uses stdlib 2. 3. Actual results: agoldste@localhost:~/go/src/github.com/openshift/docker-source-to-images/go/sti (master) go install go install runtime/cgo: open /usr/lib/golang/pkg/linux_amd64/runtime/cgo.a: permission denied Expected results: successful compile Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 48

[Bug 1096816] New: useradd within EL6 container fails: failure while writing changes to /etc/passwd
by Red Hat Bugzilla 14 Oct '14

14 Oct '14

https://bugzilla.redhat.com/show_bug.cgi?id=1096816 Bug ID: 1096816 Summary: useradd within EL6 container fails: failure while writing changes to /etc/passwd Product: Red Hat Enterprise Linux 6 Version: 6.5 Component: libselinux Assignee: dwalsh(a)redhat.com Reporter: dwalsh(a)redhat.com QA Contact: qe-baseos-security(a)redhat.com CC: admiller(a)redhat.com, dcleal(a)redhat.com, dwalsh(a)redhat.com, golang(a)lists.fedoraproject.org, jpazdziora(a)redhat.com, jumanjiman(a)gmail.com, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com Depends On: 1096123 +++ This bug was initially created as a clone of Bug #1096123 +++ Description of problem: Between docker-io-0.10.0-2.fc20 and docker-io-0.11.1-1.fc20, the following has started failing: $ docker run -t centos /usr/sbin/useradd test useradd: failure while writing changes to /etc/passwd 'centos' is the official CentOS 6 image (0b443ba03958). The Fedora 20 host has SELinux enforcing, and the same issue occurs when set to permissive. No AVCs are seen. Version-Release number of selected component (if applicable): docker-io-0.11.1-1.fc20.x86_64 kernel-3.14.2-200.fc20.x86_64 How reproducible: Always Steps to Reproduce: 1. docker pull centos 2. docker run -t centos /usr/sbin/useradd test Actual results: useradd: failure while writing changes to /etc/passwd Expected results: no output Additional info: On 0.10.0, an strace of useradd shows: open("/etc/group", O_RDONLY|O_CLOEXEC) = 11 fstat(11, {st_mode=S_IFREG|0644, st_size=379, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feb5efe5000 read(11, "root:x:0:\nbin:x:1:bin,daemon\ndae"..., 4096) = 379 close(11) = 0 munmap(0x7feb5efe5000, 4096) = 0 fchown(10, 500, 12) = 0 fchmod(10, 0660) = 0 fsync(10) = 0 close(10) = 0 fstat(6, {st_mode=S_IFREG|0644, st_size=670, ...}) = 0 gettid() = 14 open("/proc/self/task/14/attr/fscreate", O_RDONLY) = 10 read(10, "", 4095) = 0 close(10) = 0 gettid() = 14 open("/proc/self/task/14/attr/fscreate", O_RDWR) = 10 write(10, "system_u:object_r:file_t:s0\0", 28) = 28 close(10) = 0 fstat(6, {st_mode=S_IFREG|0644, st_size=670, ...}) = 0 umask(077) = 022 open("/etc/passwd-", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 10 umask(022) = 077 lseek(6, 0, SEEK_SET) = 0 read(6, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 670 fstat(10, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feb5efe5000 read(6, "", 4096) = 0 write(10, "root:x:0:0:root:/root:/bin/bash\n"..., 670) = 670 While on 0.11.1, strace shows: open("/etc/group", O_RDONLY|O_CLOEXEC) = 10 fstat(10, {st_mode=S_IFREG|0644, st_size=379, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2905a38000 read(10, "root:x:0:\nbin:x:1:bin,daemon\ndae"..., 4096) = 379 close(10) = 0 munmap(0x7f2905a38000, 4096) = 0 fchown(9, 500, 12) = 0 fchmod(9, 0660) = 0 fsync(9) = 0 close(9) = 0 fstat(5, {st_mode=S_IFREG|0644, st_size=675, ...}) = 0 gettid() = 30 open("/proc/self/task/30/attr/fscreate", O_RDONLY) = 9 read(9, "", 4095) = 0 close(9) = 0 gettid() = 30 open("/proc/self/task/30/attr/fscreate", O_RDWR) = -1 EROFS (Read-only file system) write(2, "useradd: failure while writing c"..., 54useradd: failure while writing changes to /etc/passwd ) = 54 --- Additional comment from Dominic Cleal on 2014-05-09 07:13:07 EDT --- useradd is just calling libselinux's setfscreatecon, which is being blocked. On 0.11.1, this library call fails, on 0.10.0/0.9 it works. --- Additional comment from Paul Morgan on 2014-05-09 09:55:15 EDT --- when selinux=disabled, i cannot reproduce the bug. when selinux is enabled (permissive), the bug is always reproducible. i reproduced using two docker service configs: * first, use default systemd unit * second, add `--selinux-enabled` as described at http://blog.docker.io/2014/05/docker-0-11-release-candidate-for-1-0/ override default systemd unit... # cp /usr/lib/systemd/system/docker.service /etc/systemd/system/ # vim /etc/systemd/system/docker.service # cat !$ [Unit] Description=Docker Application Container Engine Documentation=http://docs.docker.io After=network.target [Service] ExecStart=/usr/bin/docker -d --selinux-enabled Restart=on-failure LimitNOFILE=1048576 LimitNPROC=1048576 [Install] WantedBy=multi-user.target # systemctl restart docker.service # systemctl status docker.service docker.service - Docker Application Container Engine Loaded: loaded (/etc/systemd/system/docker.service; enabled) Active: active (running) since Fri 2014-05-09 09:52:25 EDT; 4s ago Docs: http://docs.docker.io Main PID: 997 (docker) CGroup: /system.slice/docker.service └─997 /usr/bin/docker -d --selinux-enabled other system info: $ rpm -q selinux-policy-targeted selinux-policy-targeted-3.12.1-158.fc20.noarch $ uname -a Linux f20-01.example.com 3.13.9-200.fc20.x86_64 #1 SMP Fri Apr 4 12:13:05 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ rpm -q docker-io docker-io-0.11.1-1.fc20.x86_64 $ docker version Client version: 0.11.1 Client API version: 1.11 Go version (client): go1.2.1 Git commit (client): fb99f99/0.11.1 Server version: 0.11.1 Server API version: 1.11 Git commit (server): fb99f99/0.11.1 Go version (server): go1.2.1 Last stable version: 0.11.1 $ docker images | grep '^centos' centos centos6 0b443ba03958 3 weeks ago 297.6 MB centos latest 0b443ba03958 3 weeks ago 297.6 MB centos 6.4 539c0211cd76 13 months ago 300.6 MB --- Additional comment from Lokesh Mandvekar on 2014-05-09 13:41:51 EDT --- I have a new scratch build http://kojipkgs.fedoraproject.org//work/tasks/2230/6832230/docker-io-0.11.1… with this build, this error doesn't occur with fedora:20, but still does with centos dwalsh, comments? --- Additional comment from Dominic Cleal on 2014-05-09 13:45:57 EDT --- Comparing the straces between el6 and fedora:20, I don't see any of the same accesses to attr/fscreate on f20 that are in the bug description. The source of shadow-utils between el6 & f20 looks very different too, I can't see any setfscreatecon calls in the useradd code path. --- Additional comment from Daniel Walsh on 2014-05-09 16:51:06 EDT --- The problem is inside the container it sees SELinux as being enabled, which is the bug. If you do id -Z, does it complain inside the container? docker run --rm -t -i fedora sh sh-4.2# id -Z id: --context (-Z) works only on an SELinux-enabled kernel sh-4.2# mount | grep /sys sysfs on /sys type sysfs (ro,relatime,seclabel) SELinux sees the container as being disabled since /sys/fs/selinux is mounted as read/only, this will tell useradd NOT to try to do any SELinux stuff while in the container. --- Additional comment from Fedora Update System on 2014-05-10 00:04:23 EDT --- docker-io-0.11.1-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/docker-io-0.11.1-3.fc20 --- Additional comment from Dominic Cleal on 2014-05-10 08:01:14 EDT --- (In reply to Daniel Walsh from comment #5) > The problem is inside the container it sees SELinux as being enabled, which > is the bug. > > If you do id -Z, does it complain inside the container? No, it runs and reports a context. > docker run --rm -t -i fedora sh > sh-4.2# id -Z > id: --context (-Z) works only on an SELinux-enabled kernel > sh-4.2# mount | grep /sys > sysfs on /sys type sysfs (ro,relatime,seclabel) $ rpm -q docker-io docker-io-0.9.1-1.fc20.x86_64 $ docker run -i -t centos /bin/bash bash-4.1# id -Z system_u:system_r:docker_t:s0 bash-4.1# mount | grep sys sysfs on /sys type sysfs (rw,seclabel,nosuid,nodev,noexec,relatime) $ rpm -q docker-io docker-io-0.11.1-3.fc20.x86_64 $ docker run -i -t centos /bin/bash bash-4.1# id -Z system_u:system_r:svirt_lxc_net_t:s0:c231,c400 bash-4.1# mount | grep /sys sysfs on /sys type sysfs (ro,seclabel,relatime) > SELinux sees the container as being disabled since /sys/fs/selinux is > mounted as read/only, this will tell useradd NOT to try to do any SELinux > stuff while in the container. /sys is correctly read-only as you expected, but it seems useradd's still doing SELinux stuff then. These packages are installed inside the EL6 container: libselinux-2.0.94-5.3.el6_4.1.x86_64 libselinux-utils-2.0.94-5.3.el6_4.1.x86_64 shadow-utils-4.1.4.2-13.el6.x86_64 Calling is_selinux_enabled() on Fedora is returning 0, while on EL6 it's returning 1. Another difference - on Fedora, getenforce returns "Disabled" but on EL6 it prints: # getenforce getenforce: getenforce() failedbash-4.1# /selinux exists within the container, but nothing is actually mounted there. It appears to be simply a directory on the root filesystem (/selinux/booleans exists as an empty dir). No other SELinux mounts are visible. Looking at libselinux-2.0.94, I think it's seeing selinuxfs listed in /proc/filesystems and assuming SELinux is enabled because of this. libselinux-2.2.1 on F20 doesn't seem to have this code. libselinux-2.0.94/src/enabled.c: /* Drop back to detecting it the long way. */ fp = fopen("/proc/filesystems", "r"); if (!fp) return -1; __fsetlocking(fp, FSETLOCKING_BYCALLER); while ((num = getline(&buf, &len, fp)) != -1) { if (strstr(buf, "selinuxfs")) { enabled = 1; break; } } # grep selinux /proc/filesystems nodev selinuxfs (All the above was tested with docker-io-0.11.1-3.fc20) --- Additional comment from Fedora Update System on 2014-05-12 01:28:00 EDT --- Package docker-io-0.11.1-3.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing docker-io-0.11.1-3.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-6281/docker-io-0.11.1-3… then log in and leave karma (feedback). --- Additional comment from Dominic Cleal on 2014-05-12 06:34:11 EDT --- (In reply to Dominic Cleal from comment #7) > Looking at libselinux-2.0.94, I think it's seeing selinuxfs listed in > /proc/filesystems and assuming SELinux is enabled because of this. > libselinux-2.2.1 on F20 doesn't seem to have this code. Bug #835146 (against EL6) seems to confirm this, suggesting a backport of the patch that removes the /proc/filesystems based check. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1096123 [Bug 1096123] useradd within EL6 container fails: failure while writing changes to /etc/passwd -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Bug 1109537] New: gear command line cannot be run with a confined user
by Red Hat Bugzilla 28 Sep '14

28 Sep '14

https://bugzilla.redhat.com/show_bug.cgi?id=1109537 Bug ID: 1109537 Summary: gear command line cannot be run with a confined user Product: Fedora Version: 20 Component: geard Assignee: lsm5(a)redhat.com Reporter: misc(a)zarb.org QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com Description of problem: $ gear zsh: permission denied: gear $ id -Z staff_u:staff_r:staff_t:s0-s0:c0.c1023 WIth setenforce 0, it work fine. # rpm -q selinux-policy selinux-policy-3.12.1-166.fc20.noarch I am not sure if gear can be run as a simple user, but i would at least expect to be able to see the command line options, since there is no manpage. -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1069718] New: Kernel container scalability issue in docker - VFS and mount path consuming too much CPU
by Red Hat Bugzilla 15 Sep '14

15 Sep '14

https://bugzilla.redhat.com/show_bug.cgi?id=1069718 Bug ID: 1069718 Summary: Kernel container scalability issue in docker - VFS and mount path consuming too much CPU Product: Red Hat Enterprise Linux 7 Version: 7.0 Component: systemd Severity: urgent Priority: urgent Assignee: systemd-maint(a)redhat.com Reporter: sct(a)redhat.com QA Contact: qe-baseos-daemons(a)redhat.com CC: agk(a)redhat.com, alexl(a)redhat.com, fs-maint(a)redhat.com, fweimer(a)redhat.com, golang(a)lists.fedoraproject.org, ikent(a)redhat.com, jeder(a)redhat.com, jpoimboe(a)redhat.com, lsm5(a)redhat.com, lvm-team(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, mjenner(a)redhat.com, perfbz(a)redhat.com, rwheeler(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com Depends On: 1061359, 1064929 Group: private Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1061359 [Bug 1061359] improve docker devicemapper backend scalability https://bugzilla.redhat.com/show_bug.cgi?id=1064929 [Bug 1064929] Kernel container scalability issue in docker - VFS and mount path consuming too much CPU -- You are receiving this mail because: You are on the CC list for the bug.

1 27

[Bug 1064929] New: Kernel container scalability issue in docker devicemapper backend
by Red Hat Bugzilla 15 Sep '14

15 Sep '14

https://bugzilla.redhat.com/show_bug.cgi?id=1064929 Bug ID: 1064929 Summary: Kernel container scalability issue in docker devicemapper backend Product: Red Hat Enterprise Linux 7 Version: 7.0 Component: kernel Severity: high Assignee: kernel-mgr(a)redhat.com Reporter: sct(a)redhat.com QA Contact: kernel-qe(a)redhat.com CC: agk(a)redhat.com, alexl(a)redhat.com, golang(a)lists.fedoraproject.org, jeder(a)redhat.com, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com Depends On: 1061359 Blocks: 1064012 Group: private Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1061359 [Bug 1061359] improve docker devicemapper backend scalability https://bugzilla.redhat.com/show_bug.cgi?id=1064012 [Bug 1064012] improve docker devicemapper backend scalability -- You are receiving this mail because: You are on the CC list for the bug.

1 22

[Bug 1064012] New: improve docker devicemapper backend scalability
by Red Hat Bugzilla 15 Sep '14

15 Sep '14

https://bugzilla.redhat.com/show_bug.cgi?id=1064012 Bug ID: 1064012 Summary: improve docker devicemapper backend scalability Product: Red Hat Enterprise Linux 7 Version: 7.0 Component: docker Severity: high Assignee: lsm5(a)redhat.com Reporter: jeder(a)redhat.com QA Contact: virt-bugs(a)redhat.com CC: agk(a)redhat.com, alexl(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com Depends On: 1061359 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1061359 [Bug 1061359] improve docker devicemapper backend scalability -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1061359] New: improve docker devicemapper backend scalability
by Red Hat Bugzilla 15 Sep '14

15 Sep '14

https://bugzilla.redhat.com/show_bug.cgi?id=1061359 Bug ID: 1061359 Summary: improve docker devicemapper backend scalability Product: Fedora Version: rawhide Component: docker-io Severity: high Assignee: lsm5(a)redhat.com Reporter: jeder(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: golang(a)lists.fedoraproject.org, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 1111233] New: RHEL6: docker run fails on --privileged
by Red Hat Bugzilla 15 Sep '14

15 Sep '14

https://bugzilla.redhat.com/show_bug.cgi?id=1111233 Bug ID: 1111233 Summary: RHEL6: docker run fails on --privileged Product: Fedora Version: rawhide Component: docker-io Assignee: lsm5(a)redhat.com Reporter: vbatts(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.com, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com Description of problem: running a privileged container should not fail, but it does Version-Release number of selected component (if applicable): docker-io-1.0.0-3.el6.x86_64 How reproducible: consistent Steps to Reproduce: 1. docker run -it --rm --privileged fedora echo HOWDY 2. 3. Actual results: 2014/06/19 09:58:45 Error: Cannot start container 807ea2ed77cdd98dd7dd5600aa363be6ae64c022a03dde70e033d5e7283808ab: stat /dev/.udev/db/bsg:0:0:0:0: no such file or directory Expected results: HOWDY Additional info: This appears to already be resolved in docker/master branch. -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1111812] New: docker-io-1.0.1 is available
by Red Hat Bugzilla 14 Aug '14

14 Aug '14

https://bugzilla.redhat.com/show_bug.cgi?id=1111812 Bug ID: 1111812 Summary: docker-io-1.0.1 is available Product: Fedora Version: rawhide Component: docker-io Keywords: FutureFeature, Triaged Assignee: lsm5(a)redhat.com Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.com, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com Latest upstream release: 1.0.1 Current version/release in Fedora Rawhide: 1.0.0-3.fc21 URL: https://github.com/dotcloud/docker/releases Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug.

1 7

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang June 2014