[Bug 1033604] New: Unable to start systemd service in Docker container
by Red Hat Bugzilla
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.
8 years, 11 months
[Bug 1092136] New: Docker commands pause streaming audio
by Red Hat Bugzilla
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.
9 years
[Bug 1046717] New: Cancel run or pull operation doesn't actually stop the ongoing task
by Red Hat Bugzilla
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.
9 years
[Bug 1087704] New: repetition of signal 21 with --sig-proxy and SIGSTOP of docker
by Red Hat Bugzilla
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.
9 years
[Bug 1087720] New: signal 27 (SIGPROF) not passed to container using --sig-proxy
by Red Hat Bugzilla
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.
9 years
[Bug 1166312] New: etcd unit should support command line options
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1166312
Bug ID: 1166312
Summary: etcd unit should support command line options
Product: Fedora
Version: 21
Component: etcd
Assignee: lacypret(a)gmail.com
Reporter: lars(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: eparis(a)redhat.com, golang(a)lists.fedoraproject.org,
jchaloup(a)redhat.com, lacypret(a)gmail.com,
lemenkov(a)gmail.com
The "etcd.service" unit distributed with Fedora 21 (atomic) does not contain
any facilities for passing arguments to etcd. That is, it looks like this:
[Service]
Type=simple
StandardOutput=null
WorkingDirectory=/var/lib/etcd
User=etcd
ExecStart=/usr/bin/etcd
This means that if a deployer wants to pass arguments to etcd at boot (such as
a discovery URL), the only option is to introduce a new unit file in
/etc/systemd/system.
This works, but it seems like a heavy hammer.
It seems as if a better choice would be to introduce an EnvironmentFile
directive like we do for so many other units. Something like:
[Service]
Type=simple
StandardOutput=null
WorkingDirectory=/var/lib/etcd
User=etcd
EnvironmentFile=/etc/sysconfig/etcd
ExecStart=/usr/bin/etcd $OPTIONS
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years
[Bug 1166950] New: Unable to run "mysql" docker image on Fedora atomic due to selinux
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1166950
Bug ID: 1166950
Summary: Unable to run "mysql" docker image on Fedora atomic
due to selinux
Product: Fedora
Version: 21
Component: docker-io
Assignee: lsm5(a)fedoraproject.org
Reporter: lars(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, jchaloup(a)redhat.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
The "mysql" Docker image creates a volume on /var/lib/mysql inside the
container.
At runtime, the entrypoint script attempts to chown this directory to the mysql
user, which leads to the following error:
# docker run -e MYSQL_ROOT_PASSWORD=secret mysql
FATAL ERROR: Could not chown directory /var/lib/mysql
And the following AVC:
type=AVC msg=audit(1416629737.562:201): avc: denied { setattr } for
pid=22615 comm="mysql_install_d"
name="d27cb6010a47942d7dc4826ebfe138ea62888fc9a5dedcaf14ebb3a1f45781c2"
dev="dm-0" ino=6329484 scontext=system_u:system_r:svirt_lxc_net_t:s0:c190,c586
tcontext=system_u:object_r:docker_var_lib_t:s0 tclass=dir permissive=0
Which translates to:
module docker 1.0;
require {
type svirt_lxc_net_t;
type docker_var_lib_t;
class dir setattr;
}
#============= svirt_lxc_net_t ==============
allow svirt_lxc_net_t docker_var_lib_t:dir setattr;
A simple reproducer is to create a Dockerfile with the following:
FROM fedora
VOLUME /var/lib/myvolume
RUN chown nobody /var/lib/myvolume
And attempt to "docker build .":
Sending build context to Docker daemon 2.56 kB
Sending build context to Docker daemon
Step 0 : FROM fedora
---> 7d3f07f8de5f
Step 1 : VOLUME /var/lib/myvolume
---> Running in 5f2e6a9a51e0
---> ea49c8d042b2
Removing intermediate container 5f2e6a9a51e0
Step 2 : RUN chown nobody /var/lib/myvolume
---> Running in d1083d0ccc68
chown: changing ownership of '/var/lib/myvolume': Permission denied
2014/11/22 04:27:19 The command [/bin/sh -c chown nobody /var/lib/myvolume]
returned a non-zero code: 1
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years
[Bug 1165615] New: Docker needs at least device-mapper-libs-1.02.90-1 to start correcty as a systemd service
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1165615
Bug ID: 1165615
Summary: Docker needs at least device-mapper-libs-1.02.90-1 to
start correcty as a systemd service
Product: Fedora
Version: 21
Component: docker-io
Severity: low
Priority: low
Assignee: lsm5(a)fedoraproject.org
Reporter: jchaloup(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, 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:
After installing docker on clean installation of F21, systemctl start docker
fails.
Version-Release number of selected component (if applicable):
docker-io-1.3.1-2.fc21.x86_64
device-mapper-libs-1.02.88-2.fc21.x86_64
How reproducible:
Always
Steps to Reproduce:
1. install F21
2. yum install docker
3. systemctl start docker
Actual results:
docker does not start
Expected results:
docker starts
Additional info:
I don't update the system (no yum update), because I don't want to increase
system's size in virtual machine. Thus device-mapper-libs does not get updated
to the latest build.
# systemctl start docker
Job for docker.service failed. See 'systemctl status docker.service' and
'journalctl -xn' for details.
# status docker.service -l
● docker.service - Docker Application Container Engine
Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled)
Active: failed (Result: exit-code) since Wed 2014-11-19 06:04:42 EST; 1min
16s ago
Docs: http://docs.docker.com
Process: 2473 ExecStart=/usr/bin/docker -d -H fd:// $OPTIONS
$DOCKER_STORAGE_OPTIONS (code=exited, status=127)
Main PID: 2473 (code=exited, status=127)
Nov 19 06:04:42 localhost.localdomain docker[2473]: 2014/11/19 06:04:42 docker
daemon: 1.3.1 4e9bbfa/1.3.1; xecdriver: native; graphdriver:
Nov 19 06:04:42 localhost.localdomain docker[2473]: [54d8ccdb] +job
serveapi(fd://)
Nov 19 06:04:42 localhost.localdomain docker[2473]: [info] Listening for HTTP
on fd ()
Nov 19 06:04:42 localhost.localdomain docker[2473]: /usr/bin/docker: relocation
error: /usr/bin/docker: symbol dm_task_get_info_with_deferred_remove, version
Base not defined in file libdevmapper.so.1.02 with link time reference
Nov 19 06:04:42 localhost.localdomain systemd[1]: docker.service: main process
exited, code=exited, status=127/n/a
Nov 19 06:04:42 localhost.localdomain systemd[1]: Failed to start Docker
Application Container Engine.
Nov 19 06:04:42 localhost.localdomain systemd[1]: Unit docker.service entered
failed state.
Among others:
/usr/bin/docker: relocation error: /usr/bin/docker: symbol
dm_task_get_info_with_deferred_remove, version Base not defined in file
libdevmapper.so.1.02 with link time reference
Update of device-mapper-libs to device-mapper-libs-1.02.90-1 solves the
problem.
Proposing to add device-mapper-libs >= 1.02.90-1 to spec file.
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years, 1 month
[Bug 1173950] New: docker-io can't be installed on rhel 6.5 due to requirement device-mapper-libs >= 1.02.90-1
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1173950
Bug ID: 1173950
Summary: docker-io can't be installed on rhel 6.5 due to
requirement device-mapper-libs >= 1.02.90-1
Product: Fedora EPEL
Version: el6
Component: docker-io
Severity: high
Assignee: lsm5(a)redhat.com
Reporter: abonas(a)redhat.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:
docker-io.x86_64 0:1.3.2-2.el6 can't be installed on rhel 6.5 due to
requirement device-mapper-libs >= 1.02.90-1:
How reproducible:
Steps to Reproduce: (on rhel 6.5)
1. sudo yum install docker-io
2. device-mapper-libs can't be upgraded to the requested version.
3.
Actual results:
error:
Running transaction check
---> Package docker-io.x86_64 0:1.3.2-2.el6 will be installed
--> Processing Dependency: device-mapper-libs >= 1.02.90-1 for package:
docker-io-1.3.2-2.el6.x86_64
--> Finished Dependency Resolution
Error: Package: docker-io-1.3.2-2.el6.x86_64 (epel)
Requires: device-mapper-libs >= 1.02.90-1
Installed: device-mapper-libs-1.02.79-8.el6.x86_64
(@production-rhel-x86_64-workstation-6.5)
device-mapper-libs = 1.02.79-8.el6
Available: device-mapper-libs-1.02.53-8.el6.i686
(production-rhel-x86_64-workstation-6.5)
device-mapper-libs = 1.02.53-8.el6
Available: device-mapper-libs-1.02.53-8.el6_0.2.i686
(production-rhel-x86_64-workstation-6.5)
device-mapper-libs = 1.02.53-8.el6_0.2
Available: device-mapper-libs-1.02.53-8.el6_0.3.i686
(production-rhel-x86_64-workstation-6.5)
device-mapper-libs = 1.02.53-8.el6_0.3
Available: device-mapper-libs-1.02.53-8.el6_0.4.i686
(production-rhel-x86_64-workstation-6.5)
device-mapper-libs = 1.02.53-8.el6_0.4
Available: device-mapper-libs-1.02.62-3.el6.i686
(production-rhel-x86_64-workstation-6.5)
device-mapper-libs = 1.02.62-3.el6
Available: device-mapper-libs-1.02.66-6.el6.i686
(production-rhel-x86_64-workstation-6.5)
device-mapper-libs = 1.02.66-6.el6
Available: device-mapper-libs-1.02.74-10.el6.i686
(production-rhel-x86_64-workstation-6.5)
device-mapper-libs = 1.02.74-10.el6
Available: device-mapper-libs-1.02.74-10.el6_3.2.i686
(production-rhel-x86_64-workstation-6.5)
device-mapper-libs = 1.02.74-10.el6_3.2
Available: device-mapper-libs-1.02.74-10.el6_3.3.i686
(production-rhel-x86_64-workstation-6.5)
device-mapper-libs = 1.02.74-10.el6_3.3
Available: device-mapper-libs-1.02.77-9.el6.i686
(production-rhel-x86_64-workstation-6.5)
device-mapper-libs = 1.02.77-9.el6
Available: device-mapper-libs-1.02.77-9.el6_4.2.i686
(production-rhel-x86_64-workstation-6.5)
device-mapper-libs = 1.02.77-9.el6_4.2
Available: device-mapper-libs-1.02.77-9.el6_4.3.i686
(production-rhel-x86_64-workstation-6.5)
device-mapper-libs = 1.02.77-9.el6_4.3
Expected results:
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years, 1 month