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.
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.
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.
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.
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.
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.
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.
https://bugzilla.redhat.com/show_bug.cgi?id=1128208
Bug ID: 1128208
Summary: docker io not using proper DNS
Product: Fedora
Version: 20
Component: docker-io
Assignee: lsm5(a)fedoraproject.org
Reporter: briemers(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, dgoodwin(a)redhat.com,
eparis(a)redhat.com, extras-qa(a)fedoraproject.org,
gansalmon(a)Gmail.com, golang(a)lists.fedoraproject.org,
hushan.jia(a)gmail.com, itamar(a)ispbrasil.com.br,
jeder(a)redhat.com, jonathan(a)jonmasters.org,
jpazdziora(a)redhat.com, jperrin(a)centos.org,
kernel-maint(a)redhat.com, lars(a)redhat.com,
lsm5(a)fedoraproject.org, madhu.chinakonda(a)gmail.com,
mattdm(a)redhat.com, mchehab(a)infradead.org,
mgoldman(a)redhat.com, pmoore(a)redhat.com,
rbriggs(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com
Depends On: 1119849
The resolution for Bug #1119849 introduced a new problem.
I have a dockerfile that uses the command:
git clone http://gitolite.corp.redhat.com/cgit/it-sales/sfjavasuite.git/
Up until the most recent update the dockerfile worked expected. Now it fails
with a hostname not found.
It seems part of the update is docker will now try and use fixed DNS values of
8.8.8.8 and 8.8.4.4. Which is of course in appropriate for anyone inside a
private network. In some cases it is even considered a security risk to have
DNS lookups leak to a public DNS server, as it gives outside user information
about the private network.
It is possible to update the docker options to work around the problem. But
of course the DNS servers obtained by DHCP, so it would require restarting
docker-io with new settings everytime a new network connection is
established...
Likewise another workaround is a set if iptable rules to override all DNS
lookups but again this introduces it's own set of problems.
And of course, I don't want to assume everyone who will use my Dockerfile has
updated their workstations and servers with whatever hack solution I use...
Reproduce steps:
1. docker run fedora cat /etc/resolv.conf
Expected results:
The DNS settings equivalent to the host, which in my case are:
$ cat /etc/resolv.conf
# Generated by NetworkManager
domain docbill.info
search docbill.info
nameserver 127.0.0.1
nameserver 172.31.253.1
nameserver 172.31.252.1
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 10.11.255.155
nameserver 10.11.255.156
nameserver 10.5.26.21
nameserver 10.7.142.20
nameserver fe80::beae:c5ff:fee8:b5e%em1
nameserver fe80::4216:7eff:feea:a5b8%em1
nameserver 2001:470:1d:8a2::1
Actual results:
$ docker run fedora cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
search docbill.info
Note: I'm not sure how the previous docker-io version got the 127.0.0.1
correct. But somehow it figured out that was an instruction to use the dnsmasq
instance on my laptop.
Bill
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1119849
[Bug 1119849] su - postgres Results in System Error inside Fedora
20/rawhide containers
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1118234
Bug ID: 1118234
Summary: Docker doesn't update DNS IP when it's changed on
system
Product: Fedora EPEL
Version: epel7
Component: docker-io
Severity: medium
Assignee: lsm5(a)switzerlandmail.ch
Reporter: maxime.carron(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)switzerlandmail.ch,
mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io,
vbatts(a)redhat.com
Description of problem:
When the DNS server is changed on the system, docker keep using the one used at
its startup.
Version-Release number of selected component (if applicable):
EL 7.0
docker : 1.0.0-1
How reproducible:
Always.
Steps to Reproduce:
1. Start docker (systemctl start docker)
2. Do any operation which needs DNS resolution (docker pull fedora:latest)
=> System DNS is used
3. Change system DNS to 8.8.8.8 or any different DNS
4. Do some other operation which needs DNS resolution (docker pull
fedora:rawhide)
5. You should see that first is still used
Actual results:
No DNS update
Expected results:
Docker should use the current system DNS
Additional info:
This is especially disturbing on a laptop, because a docker restart is needed
everytime I change network (when first DNS is not reachable anymore, usually
when DNS has a private IP)
--
You are receiving this mail because:
You are on the CC list for the bug.
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.