golang June 2014

golang@lists.fedoraproject.org

1 participants
94 discussions

[Bug 1096076] New: ADDing file to symlinked /bin hangs, docker process spinning at 100 % CPU
by Red Hat Bugzilla 25 Jun '14

25 Jun '14

https://bugzilla.redhat.com/show_bug.cgi?id=1096076 Bug ID: 1096076 Summary: ADDing file to symlinked /bin hangs, docker process spinning at 100 % CPU Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: jpazdziora(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: On Fedora 20, /bin is a symlink to usr/bin. When Dockerfile tries to ADD file to /bin, the process will hang, with the daemon spinning at 100 % CPU. Version-Release number of selected component (if applicable): docker-io-0.11.1-1.fc20.x86_64 Seen on 0.10* as well. How reproducible: Deterministic. Steps to Reproduce: 1. echo test > testfile 2. have Dockerfile with FROM fedora:20 ADD testfile /bin/testfile 3. run docker build -t test-symlink . Actual results: Uploading context 4.608 kB Uploading context Step 0 : FROM fedora:20 ---> b7de3133ff98 Step 1 : ADD testfile /bin/testfile and that's it, top in another terminal shows Expected results: # docker build -t test-symlink . Uploading context 5.632 kB Uploading context Step 0 : FROM fedora:20 ---> b7de3133ff98 Step 1 : ADD testfile /bin/testfile ---> 6fb52b6363f7 Removing intermediate container 11254a256eb7 Successfully built 6fb52b6363f7 # Additional info: ADD to /usr/bin/testfile works. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1105789] New: docker-io-0.12.0 is available
by Red Hat Bugzilla 25 Jun '14

25 Jun '14

https://bugzilla.redhat.com/show_bug.cgi?id=1105789 Bug ID: 1105789 Summary: docker-io-0.12.0 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, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com Latest upstream release: 0.12.0 Current version/release in Fedora Rawhide: 0.11.1-11.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 8

[Bug 1094664] New: docker-io-0.10.0-2 disables access to /dev/shm
by Red Hat Bugzilla 24 Jun '14

24 Jun '14

https://bugzilla.redhat.com/show_bug.cgi?id=1094664 Bug ID: 1094664 Summary: docker-io-0.10.0-2 disables access to /dev/shm Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: jpazdziora(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: While testing FreeIPA server and the 389 server in Docker container, I started to see errors like Failed to create semaphore for stats file/Permission denied with docker-io from updates-testing. Upon closer look, /dev/shm seems to be mounted with 1755, which is different from what docker-io 0.9.1 does and what you get on bare metal. Version-Release number of selected component (if applicable): docker-io-0.10.0-2.fc20.x86_64 How reproducible: Deterministic. Steps to Reproduce: 1. docker run -ti fedora:20 /bin/bash 2. In the container shell, run mount | grep /dev/shm ls -la /dev/shm exit 3. Downgrade to docker-io-0.9.1 and repeat. Actual results: # docker run -ti fedora:20 /bin/bash bash-4.2# mount | grep /dev/shm shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,seclabel,size=65536k,mode=1755) # docker run -ti fedora:20 /bin/bash bash-4.2# ls -la /dev/shm total 4 drwxrwxrwt. 2 root root 40 May 6 08:06 . drwxr-xr-x. 4 root root 4096 May 6 08:06 .. bash-4.2# exit # rpm -q docker-io docker-io-0.9.1-1.fc20.x86_64 # yum downgrade docker-io -y [...] # rpm -q docker-io docker-io-0.9.1-1.fc20.x86_64 # docker run -ti fedora:20 /bin/bash bash-4.2# mount | grep /dev/shm shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,seclabel,size=65536k) bash-4.2# ls -la /dev/shm total 4 drwxrwxrwt. 2 root root 40 May 6 09:16 . drwxr-xr-x. 4 root root 4096 May 6 09:16 .. bash-4.2# exit exit # Expected results: Permissions on /dev/shm the same as on docker-io-0.9.1. Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 8

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

24 Jun '14

https://bugzilla.redhat.com/show_bug.cgi?id=1096123 Bug ID: 1096123 Summary: useradd within EL6 container fails: failure while writing changes to /etc/passwd Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: dcleal(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: 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 -- You are receiving this mail because: You are on the CC list for the bug.

1 40

[Bug 1103595] New: Docker daemon uses 100 % CPU
by Red Hat Bugzilla 23 Jun '14

23 Jun '14

https://bugzilla.redhat.com/show_bug.cgi?id=1103595 Bug ID: 1103595 Summary: Docker daemon uses 100 % CPU Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: jpazdziora(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 run docker build which downloads images. While this happens, the docker daemon is using up-to 100 % CPU when it probably does not have that much work to do, given the speed of my network. Version-Release number of selected component (if applicable): # rpm -qf /usr/bin/docker docker-io-0.11.1-7.fc20.x86_64 How reproducible: Seen once. Steps to Reproduce: 1. ( echo FROM fedora:20 ; ADD testfile /bin/testfile ) > Dockerfile 2. docker build -t test-1 . 3. In other terminal, observe top while the images are being downloaded. Actual results: # docker build -t test-1 . Uploading context 3.584 kB Uploading context Step 0 : FROM fedora:20 Pulling repository fedora 4f4eba4c47b8: Downloading [===========================================> ] 101.4 MB/115.9 MB 5s 511136ea3c5a: Download complete 8c982ec5ea99: Download complete and while the download is running # top top - 03:26:45 up 6 days, 36 min, 2 users, load average: 0.58, 0.30, 0.17 Tasks: 153 total, 2 running, 151 sleeping, 0 stopped, 0 zombie %Cpu(s): 14.8 us, 11.3 sy, 0.0 ni, 43.9 id, 27.1 wa, 1.8 hi, 1.1 si, 0.0 st KiB Mem: 8160392 total, 4357084 used, 3803308 free, 176932 buffers KiB Swap: 8273916 total, 0 used, 8273916 free, 3490916 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 16112 root 20 0 588820 35144 7144 S 97.3 0.4 1:31.79 docker 16119 root 0 -20 0 0 0 S 3.6 0.0 0:04.29 loop0 and # ps axuw | grep docker root 16112 7.6 0.4 588820 36176 ? Ssl 03:05 1:37 /usr/bin/docker -d --selinux-enabled root 16287 0.3 0.0 284764 5308 pts/0 Sl+ 03:26 0:00 docker build -t test-1 . root 16341 0.0 0.0 112668 964 pts/1 S+ 03:26 0:00 grep --color=auto docker Expected results: I'd expect the daemon not consuming 100 % CPU when the only action happening is download of images on fairly slow line. Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1103323] New: docker on RHEL6.5 no longer needs to default to lxc
by Red Hat Bugzilla 18 Jun '14

18 Jun '14

https://bugzilla.redhat.com/show_bug.cgi?id=1103323 Bug ID: 1103323 Summary: docker on RHEL6.5 no longer needs to default to lxc 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, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com Description of problem: docker daemon on RHEL6 (and centos) is patched to launch with 'lxc' execdriver, instead of the docker 'native' libcontainer Version-Release number of selected component (if applicable): $ 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 The reason we had mad this switch was due to the network bridge setup for libcontainer had not worked correctly at first. This has since been fixed upstream. $ docker run -it fedora ping -c1 google.com PING google.com (173.194.121.1) 56(84) bytes of data. 64 bytes from iad23s25-in-f1.1e100.net (173.194.121.1): icmp_seq=1 ttl=45 time=16.2 ms --- google.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 16.294/16.294/16.294/0.000 ms -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1087546] New: Request epel7 branch
by Red Hat Bugzilla 18 Jun '14

18 Jun '14

https://bugzilla.redhat.com/show_bug.cgi?id=1087546 Bug ID: 1087546 Summary: Request epel7 branch Product: Fedora EPEL Version: epel7 Component: golang-github-coreos-go-systemd Assignee: lsm5(a)redhat.com Reporter: lsm5(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: bobbypowers(a)gmail.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com Package Change Request ====================== Package Name: golang-github-coreos-go-systemd New Branches: epel7 Owners: lsm5 InitialCC: golang-sig -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1072041] New: Include a -devel that provides the docker source
by Red Hat Bugzilla 17 Jun '14

17 Jun '14

https://bugzilla.redhat.com/show_bug.cgi?id=1072041 Bug ID: 1072041 Summary: Include a -devel that provides the docker source 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, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com For client tooling, that uses internal packages of docker, the docker source needs to available as a library. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1099984] Pam issue when trying to login to a container running sshd.
by Red Hat Bugzilla 17 Jun '14

17 Jun '14

https://bugzilla.redhat.com/show_bug.cgi?id=1099984 Daniel Walsh <dwalsh(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|docker-io |pam Assignee|lsm5(a)redhat.com |tmraz(a)redhat.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1102019] New: cannot remove /var/lib/docker just after a fresh install even when docker is stopped
by Red Hat Bugzilla 17 Jun '14

17 Jun '14

https://bugzilla.redhat.com/show_bug.cgi?id=1102019 Bug ID: 1102019 Summary: cannot remove /var/lib/docker just after a fresh install even when docker is stopped Product: Fedora EPEL Version: el6 Component: docker-io Severity: medium Priority: medium Assignee: lsm5(a)redhat.com Reporter: vdasgupt(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: Cannot remove /var/lib/docker just after a fresh install even when docker is stopped. And even though the docker runtime root has been changed to /home/docker and is no longer /var/lib/docker # rmdir /var/lib/docker rmdir: failed to remove `/var/lib/docker': Device or resource busy lsof does not show anyone using this file/dir Version-Release number of selected component (if applicable): RHEL 6 Kernel 2.6.32-431.el6 Docker version 0.11.1, build fb99f99/0.11.1 Steps to Reproduce: 1. yum -y docker-io 2. service docker start ; service docker stop 3. add -g="/home/docker" to other_args in /etc/sysconfig/docker 4. service docker start ; service docker stop 5. checked that the docker runtime env files are now in /home/docker 6. Try to remove or rename /var/lib/docker and it does not allow Actual results: rmdir: failed to remove `/var/lib/docker': Device or resource busy Expected results: Should have removed or allowed to rename the directory -- You are receiving this mail because: You are on the CC list for the bug.

1 3

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang June 2014