golang March 2015

golang@lists.fedoraproject.org

8 participants
437 discussions

[Bug 1140405] New: systemctl start docker fails because systemd continuously restarts the daemon
by Red Hat Bugzilla 29 Jun '15

29 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1140405 Bug ID: 1140405 Summary: systemctl start docker fails because systemd continuously restarts the daemon Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)fedoraproject.org Reporter: a.badger(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.com, jperrin(a)centos.org, lsm5(a)fedoraproject.org, mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com Description of problem: I've installed docker for the first time and tried to start it with "systemctl start docker". The systemctl command returns successfully but then trying to run docker client commands against the daemon timed out. After some poking around I discovered that systemd was starting docker. Docker was taking quite a while to do various initialization tasks including invoking mkfs. systemd decided that docker was unresponsive and terminated it and then restarted it. Because mkfs hadn't finished, docker had to try running mkfs again. This cycle kept continuing and would probably have prevented docker from fully starting up forever. I worked around the problem by telling systemd not to start docker, running the docker daemon manually from a shell, waiting until the mkfs had completed, then shutting down my daemon and rerunning systemctl start docker. After that, the docker service runs fine. Version-Release number of selected component (if applicable): docker-io-1.2.0-2.fc20.x86_64 How reproducible: Everytime for me until after I ran docker as a daemon manually. I don't know how to reproduce once docker has initialized (Probably removing some file or volume but I don't know what it would be). Steps to Reproduce: 1. On a system that hasn't had docker running before 2. yum install docker-io 3. systemctl start docker 4. watch the output of systemctl status docker -l Actual results: systemctl status docker -l will report that docker is in state Activating for several minutes, then show that systemd decided docker wasn't responding, terminate it, and restart. The -l output will also show that docker is running mkfs for most of that time and is still running it when docker is terminated. Expected results: systemctl status docker -l will show that the state has gone to active (running) Additional info: * My filesystem is ext4. The docker initialization is running mkfs.ext4 * I'm using a 4-5 year old laptop with platter HDs. A faster machine or SSD drives might run mkfs quickly enough to not see this issue. * This might be "fixed" by adding some documentation that says to perform certain steps to initialize docker before running systemctl start docker rather than changing docker code to finish initialization sooner. -- You are receiving this mail because: You are on the CC list for the bug.

1 15

[Bug 1123057] New: warning: file /usr/bin/gofmt: remove failed: No such file or directory while removing golang packages
by Red Hat Bugzilla 29 Jun '15

29 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1123057 Bug ID: 1123057 Summary: warning: file /usr/bin/gofmt: remove failed: No such file or directory while removing golang packages Product: Fedora Version: 20 Component: golang Assignee: vbatts(a)redhat.com Reporter: dominik(a)greysector.net QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lemenkov(a)gmail.com, lsm5(a)fedoraproject.org, renich(a)woralelandia.com, s(a)shk.io, vbatts(a)redhat.com Description of problem: There are two warnings while removing golang-pkg-bin-linux-amd64 package: warning: file /usr/bin/gofmt: remove failed: No such file or directory warning: file /usr/bin/go: remove failed: No such file or directory Version-Release number of selected component (if applicable): 1.2.2-7.fc20 How reproducible: Always Steps to Reproduce: 1. yum install golang 2. yum remove golang\* Actual Results: # yum remove golang\* Loaded plugins: changelog, langpacks Resolving Dependencies --> Running transaction check ---> Package golang.x86_64 0:1.2.2-7.fc20 will be erased ---> Package golang-pkg-bin-linux-amd64.x86_64 0:1.2.2-7.fc20 will be erased ---> Package golang-pkg-linux-amd64.noarch 0:1.2.2-7.fc20 will be erased ---> Package golang-src.noarch 0:1.2.2-7.fc20 will be erased --> Finished Dependency Resolution [...] Running transaction (shutdown inhibited) Erasing : golang-pkg-linux-amd64-1.2.2-7.fc20.noarch 1/4 Erasing : golang-pkg-bin-linux-amd64-1.2.2-7.fc20.x86_64 2/4 warning: file /usr/bin/gofmt: remove failed: No such file or directory warning: file /usr/bin/go: remove failed: No such file or directory Erasing : golang-1.2.2-7.fc20.x86_64 3/4 Erasing : golang-src-1.2.2-7.fc20.noarch 4/4 Verifying : golang-src-1.2.2-7.fc20.noarch 1/4 Verifying : golang-1.2.2-7.fc20.x86_64 2/4 Verifying : golang-pkg-bin-linux-amd64-1.2.2-7.fc20.x86_64 3/4 Verifying : golang-pkg-linux-amd64-1.2.2-7.fc20.noarch 4/4 Removed: golang.x86_64 0:1.2.2-7.fc20 golang-pkg-bin-linux-amd64.x86_64 0:1.2.2-7.fc20 golang-pkg-linux-amd64.noarch 0:1.2.2-7.fc20 golang-src.noarch 0:1.2.2-7.fc20 Expected Results: no warning about missing files Additional Information: It looks like the links maintained by update-alternatives are not marked as %ghost in the spec file: [...] ifarch x86_64 %files pkg-bin-linux-amd64 %{goroot}/bin/linux_amd64/ # binary executables %{_bindir}/go %{_bindir}/gofmt [...] This is required by the Alternatives guideline: https://fedoraproject.org/wiki/Packaging:Alternatives . -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1075232] New: 0.9.0 Adds virtual interface, NetworkManager attempts to assign dhcp address to it
by Red Hat Bugzilla 29 Jun '15

29 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1075232 Bug ID: 1075232 Summary: 0.9.0 Adds virtual interface, NetworkManager attempts to assign dhcp address to it Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: admiller(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 Created attachment 873221 --> https://bugzilla.redhat.com/attachment.cgi?id=873221&action=edit snippet from /var/log/messages for my laptop around the virtual interface events Description of problem: When you install docker-io-0.9.0 on Fedora 20, it creates a new virtual interface 13: vethf3e3: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master docker0 state UP group default qlen 1000 link/ether 1a:9c:40:61:1e:8b brd ff:ff:ff:ff:ff:ff inet6 fe80::189c:40ff:fe61:1e8b/64 scope link valid_lft forever preferred_lft forever Something (I'm thinking dbus or udev) causes NetworkManager to launch dhclient for the new interface, and if you're running with a Desktop Environment this causes a visual change to the NM applet which can be confusing. It doesn't ever do anything, NM eventually times out and gives up and this doesn't appear to impact docker's functionality at all (or at least not yet in my tests have I found an issue, networking works fine). Version-Release number of selected component (if applicable): docker-io-0.9.0-2.fc20.x86_64 How reproducible: Always Steps to Reproduce: 1. yum install docker-io #on a machine with a GUI/DE up and running with NetworkManager Actual results: NetworkManager attempts to get a dhcp lease on the new virtual interface. Expected results: NetworkManager probably shouldn't attempt to get a dhcp lease on the new virtual interface, this seems odd. Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1033606] New: Failed to connect to network from Docker container
by Red Hat Bugzilla 17 Jun '15

17 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1033606 Bug ID: 1033606 Summary: Failed to connect to network from 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: Connecting to external network from Docker container fail due to firewalld. I guess you must have masquerade enabled, however this is not mentioned anywhere. I think docker-io should set the firewalld rules automatically, or tell users that they need to enable masquarade in firewalld. 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. $ yum install docker-io 2. $ systemctl enable docker.service 3. $ systemctl start docker.service 4. $ docker pull mattdm/fedora 5. $ docker run -i -t mattdm/fedora:latest /bin/bash 6. $ ping google.com ping: unknown host google.com When I stop firewalld on host (systemctl stop firewalld) and then restart the docker (systemctl restart docker), the ping works like a charm. Actual results: Unable to connect outside the Docker container with firewalld enabled. Expected results: Docker should configure firewalld automatically (during install?), or inform users to do so manually. Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 68

[Bug 1160833] New: Fedora 21 Beta Atomic Image: broken links, incomplete documentation, missing "docker" executable
by Red Hat Bugzilla 03 Jun '15

03 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1160833 Bug ID: 1160833 Summary: Fedora 21 Beta Atomic Image: broken links, incomplete documentation, missing "docker" executable Product: Fedora Version: 21 Component: docker-io Severity: high Assignee: lsm5(a)fedoraproject.org Reporter: znmeb(a)znmeb.net QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.com, jperrin(a)centos.org, lsm5(a)fedoraproject.org, mattdm(a)redhat.com, mgoldman(a)redhat.com, miminar(a)redhat.com, s(a)shk.io, thrcka(a)redhat.com, vbatts(a)redhat.com Description of problem: Multiple problems with Fedora 21 Beta Atomic Image: broken links, incomplete documentation, missing "docker" executable Version-Release number of selected component (if applicable): Atomic Images beta Steps to Reproduce: 1. Browse to http://fedoraproject.org/en/get-prerelease#cloud. 2. Attempt to download and discover broken link to qcow2 and raw disk images on the beta release page. 3. Find, download, verify checksum of images at http://mirror.pnl.gov/fedora/linux/releases/test/21-Beta/Cloud/Images/x86_6… 4. Prepare an initialization ISO file as described in http://www.projectatomic.io/docs/quickstart/ and https://www.technovelty.org//linux/running-cloud-images-locally.html. Note that said documentation a. Is *not* part of the Fedora documentation, which is something I expect for something carrying the "Fedora Cloud" brand, and b. Nowhere is it *explicitly* stated that the username is "fedora" or that once you log in as "fedora", "sudo su -" works to get you into "root" on the console. 5. Log in as "fedora", type "sudo su -" and type "docker ps". Actual results: '-bash: docker: command not found' Expected results: 1. Working links on the beta release page 2. Fedora-branded documentation with the username and how to obtain root. 3. Docker installed and ready to create images and containers. -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1187649] New: Fedora:latest docker image d-bus unknown error -1
by Red Hat Bugzilla 03 Jun '15

03 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1187649 Bug ID: 1187649 Summary: Fedora:latest docker image d-bus unknown error -1 Product: Fedora Version: 21 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: cyborg101010(a)gmail.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 Description of problem: When trying to use anything that relies on D-Bus, on Fedora:latest, you get the error: Failed to get D-Bus connection: Unknown error -1 How reproducible: 100% Steps to Reproduce: 1. Attach to Fedora:latest 2. yum install postgresql-server -y 3. systemctl start postgresql Actual results: Failed to get D-Bus connection: Unknown error -1 Expected results: Systemd starts postgres Additional info: It's not just postgres, I've tried with others. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1096286] New: "docker top all" doesn't show processes when --tty=false
by Red Hat Bugzilla 02 Jun '15

02 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1096286 Bug ID: 1096286 Summary: "docker top all" doesn't show processes when --tty=false Product: Red Hat Enterprise Linux 7 Version: 7.1 Component: docker Assignee: lsm5(a)redhat.com Reporter: ldoktor(a)redhat.com QA Contact: virt-bugs(a)redhat.com 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 Depends On: 1088259 +++ This bug was initially created as a clone of Bug #1088259 +++ After using the same magic required for the upstream docker 0.10 this behaves the same on RHEL docker-0.10.0-8.el7.x86_64 Description of problem: Hi guys, when I run docker with --tty=false, the `docker top $NAME all` doesn't show any processes (just headers). When using only `docker top $NAME` it shows them... Also the `ps` command inside container works, but `ps all` does not. Version-Release number of selected component (if applicable): docker-0.10.0-8.el7.x86_64 docker-io-0.9.0-3.fc20.x86_64 How reproducible: always Steps to Reproduce: 1. docker run -i --tty=false fedora bash 2. docker logs $NAME Actual results: F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND Expected results: F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 1 0 24006 23954 20 0 11732 540 - R pts/14 0:00 bash --- Additional comment from Lukas Doktor on 2014-05-05 03:41:35 EDT --- Can't reproduce with the upstream Docker version 0.10.0, build dc9c28f/0.10.0 top doesn't work at all (due of https://bugzilla.redhat.com/show_bug.cgi?id=1088125 ) --- Additional comment from Lukas Doktor on 2014-05-05 03:46:07 EDT --- OK I moved it to the old cgroup location and the results are the same. So booth, fedora docker-io-0.9.0-3.fc20.x86_64 and upstream dc9c28f/0.10.0 are unable to list processes using `all` argument in non-tty mode. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1088259 [Bug 1088259] "docker top all" doesn't show processes when --tty=false -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1088259] New: "docker top all" doesn't show processes when --tty=false
by Red Hat Bugzilla 02 Jun '15

02 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1088259 Bug ID: 1088259 Summary: "docker top all" doesn't show processes when --tty=false 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: Hi guys, when I run docker with --tty=false, the `docker top $NAME all` doesn't show any processes (just headers). When using only `docker top $NAME` it shows them... Also the `ps` command inside container works, but `ps all` does not. Version-Release number of selected component (if applicable): docker-io-0.9.0-3.fc20.x86_64 How reproducible: always Steps to Reproduce: 1. docker run -i --tty=false fedora bash 2. docker logs $NAME Actual results: F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND Expected results: F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 1 0 24006 23954 20 0 11732 540 - R pts/14 0:00 bash -- You are receiving this mail because: You are on the CC list for the bug.

1 29

[Bug 1111189] New: yumBackend started with each `docker start`
by Red Hat Bugzilla 29 May '15

29 May '15

https://bugzilla.redhat.com/show_bug.cgi?id=1111189 Bug ID: 1111189 Summary: yumBackend started with each `docker start` 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, 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: Hello guys, today I noticed 100% utilization followed by each `docker run` or `docker start`. It wasn't caused by the docker itself, but with each instance, yumBackend is executed. It never happened with older version. 4806 ? RN 0:00 /usr/bin/python /usr/share/PackageKit/helpers/yum/yuBackend.py get-updates none Version-Release number of selected component (if applicable): docker-io-1.0.0-1.fc20.x86_64 How reproducible: always Steps to Reproduce: 1. docker run -t -i fedora bash 2. top 3. ps ax |grep yum Actual results: yumBackend is started and takes couple of secconds in 100% utilization 4806 ? RN 0:00 /usr/bin/python /usr/share/PackageKit/helpers/yum/yuBackend.py get-updates none Expected results: Apart from container no other processes should be started. (I can run `docker run -t -i fedora bash -c exit` which finishes immediately and the only process using cpu is the yumBackend process) Additional info: I tried executing `busybox sh`, `bash -c exit`, .... I even rebooted the machine but the results are the same. -- You are receiving this mail because: You are on the CC list for the bug.

1 16

[Bug 1102751] New: Got "Error running removeDevice" after kill -9 docker
by Red Hat Bugzilla 29 May '15

29 May '15

https://bugzilla.redhat.com/show_bug.cgi?id=1102751 Bug ID: 1102751 Summary: Got "Error running removeDevice" after kill -9 docker 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: 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 I was playing with Docker today, I found interesting behavior: When you 'kill -9' the 'docker -d' process, then this happens: 1. The 'docker -d' process gets killed ;-) 2. All containers gets killed 3. The 'docker -d' restarts, because of Restart=on-failure Now, while all this is expected and OK, I get this when I tried to 'restart' the container that was killed in 2): May 29 13:24:56 ip-10-146-193-102 systemd[1]: Starting Container origin-db-1... May 29 13:24:56 ip-10-146-193-102 sh[19731]: Reusing b80104263de02f39bbc6d742c977ddadecb0660f5c50386eaf1cf645f3515b9c May 29 13:25:07 ip-10-146-193-102 docker[19739]: Error: Cannot destroy container origin-db-1: Driver devicemapper failed to remove root filesystem e536cf328e0083e2414c750434deb1127517d00399fddac84903825d6f003787: Error running removeDevice May 29 13:25:07 ip-10-146-193-102 docker[19739]: 2014/05/29 13:25:07 Error: failed to remove one or more containers May 29 13:25:07 ip-10-146-193-102 gear[21193]: user: unknown user ctr-origin-db-1 May 29 13:25:09 ip-10-146-193-102 docker[21192]: 2014/05/29 13:25:09 Error: Cannot start container bd1a88a35e84ef6d71fa3e1df0b4e2998318dfed6d60fd3ae381567fff2ac2a3: Cannot find child for /origin-db-1 May 29 13:25:09 ip-10-146-193-102 systemd[1]: ctr-origin-db-1.service: main process exited, code=exited, status=1/FAILURE Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Start up some containers 2. kill -9 (the 'docker -d' process pid) 3. Try to start the dead container again 4. Get the error above. Actual results: Expected results: Containers should be successfully started back. Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 5

← Newer
1
2
3
4
5
6
7
8
...
44
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang March 2015