[Bug 1140405] New: systemctl start docker fails because systemd continuously restarts the daemon
by Red Hat Bugzilla
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.
8 years, 9 months
[Bug 1123057] New: warning: file /usr/bin/gofmt: remove failed: No such file or directory while removing golang packages
by Red Hat Bugzilla
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.
8 years, 9 months
[Bug 1075232] New: 0.9.0 Adds virtual interface, NetworkManager attempts to assign dhcp address to it
by Red Hat Bugzilla
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.
8 years, 9 months
[Bug 1214619] New: Tracker for golang-github-onsi-ginkgo
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1214619
Bug ID: 1214619
Summary: Tracker for golang-github-onsi-ginkgo
Product: Fedora
Version: rawhide
Component: golang-github-onsi-ginkgo
Assignee: jchaloup(a)redhat.com
Reporter: jchaloup(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: extras-qa(a)fedoraproject.org,
golang(a)lists.fedoraproject.org, jchaloup(a)redhat.com,
lsm5(a)redhat.com, mattdm(a)redhat.com, vbatts(a)redhat.com
Tracker for async updates of golang-github-onsi-ginkgo for rawhide and other
fedora distribution.
As golang devel packages are used only as a build-time dependency at the
moment, this tracker keeps updates and other information about this package,
e.g. broken dependencies, exceptions, important pieces of information and other
issues.
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1033606] New: Failed to connect to network from Docker container
by Red Hat Bugzilla
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.
8 years, 10 months
[Bug 1215336] New: godoc uses invalid path for documentation
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1215336
Bug ID: 1215336
Summary: godoc uses invalid path for documentation
Product: Fedora
Version: 21
Component: golang
Severity: low
Assignee: vbatts(a)redhat.com
Reporter: eugene.yudin(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lemenkov(a)gmail.com, renich(a)woralelandia.com, s(a)shk.io,
vbatts(a)redhat.com
Description of problem:
Command "godoc" doesn't show documentation.
Version-Release number of selected component (if applicable):
golang-godoc.x86_64 1:0-1.0.hgd32b5854c941.fc21
How reproducible:
Always.
Steps to Reproduce:
$ godoc fmt Println
2015/04/25 18:00:38 open /usr/lib/golang/src/pkg/fmt: no such file or directory
Workaround:
# cd /usr/lib/golang/src/
# ln -s . pkg
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1160833] New: Fedora 21 Beta Atomic Image: broken links, incomplete documentation, missing "docker" executable
by Red Hat Bugzilla
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...
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.
8 years, 10 months
[Bug 1187649] New: Fedora:latest docker image d-bus unknown error -1
by Red Hat Bugzilla
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.
8 years, 10 months
[Bug 1216153] New: Docker daemon runs in shared mount namespace
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1216153
Bug ID: 1216153
Summary: Docker daemon runs in shared mount namespace
Product: Fedora EPEL
Version: el6
Component: docker-io
Assignee: ichavero(a)redhat.com
Reporter: michaeljameswells+redhatbugzilla(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,
ichavero(a)redhat.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:
The docker daemon is run in a shared mount namespace, causing problems when
restarting the docker service. This prevents starting up containers where
mounts remain in place.
Version-Release number of selected component (if applicable):
1.5.0-1.el6
How reproducible:
Always
Steps to Reproduce:
1. docker run -d --name test centos sleep infinity
2. service docker restart
3. docker start test
Actual results:
Error response from daemon: Cannot start container test: Error getting
container 0412d5cce356ff269bd85b2096eb8bc0b2cc58a67096c6c6587a85f7e82f0b77 from
driver devicemapper: Error mounting
'/dev/mapper/docker-253:0-2097716-0412d5cce356ff269bd85b2096eb8bc0b2cc58a67096c6c6587a85f7e82f0b77'
on
'/var/lib/docker/devicemapper/mnt/0412d5cce356ff269bd85b2096eb8bc0b2cc58a67096c6c6587a85f7e82f0b77':
device or resource busy
FATA[0000] Error: failed to start one or more containers
Expected results:
Container to start.
Additional info:
A merged pull request containing updated sysvinit script is found here:
https://github.com/docker/docker/pull/10225
It was merged prior to the 1.5.0 release and involves running "unshare -m" when
starting the docker daemon to place it into its own mount namespace.
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1216265] New: docker exec -it bash cannot start a shell session
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1216265
Bug ID: 1216265
Summary: docker exec -it bash cannot start a shell session
Product: Fedora
Version: 22
Component: docker-io
Severity: high
Assignee: ichavero(a)redhat.com
Reporter: robberphex(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,
ichavero(a)redhat.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:
`docker exec -it <name> /bin/bash` cannot work
Version-Release number of selected component (if applicable):
$ uname -a
Linux rp.fedora 4.0.0-0.rc5.git4.1.fc22.x86_64 #1 SMP Fri Mar 27 13:51:23 UTC
2015 x86_64 x86_64 x86_64 GNU/Linux
$ sudo docker version
Client version: 1.6.0
Client API version: 1.18
Go version (client): go1.4.2
Git commit (client): 0591dce/1.6.0
OS/Arch (client): linux/amd64
Server version: 1.6.0
Server API version: 1.18
Go version (server): go1.4.2
Git commit (server): 0591dce/1.6.0
OS/Arch (server): linux/amd64
How reproducible:
Steps to Reproduce:
1. `sudo docker run --name some-nginx -d nginx:1.7`
2. `sudo docker exec -it some-nginx /bin/bash`
Actual results:
<no output>
Expected results:
start a bash session
Additional info:
`sudo docker exec -it some-nginx echo hello` also have no ouput.
but `sudo docker exec some-nginx echo hello` get the output('hello').
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months