[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 1195804] New: docker run fails on rawhide with setenforce 1
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1195804
Bug ID: 1195804
Summary: docker run fails on rawhide with setenforce 1
Product: Fedora
Version: rawhide
Component: docker-io
Assignee: lsm5(a)redhat.com
Reporter: lsm5(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:
On rawhide, docker run commands fail with selinux enforcing.
Feb 24 09:34:01 naruto kernel: [605832.428983] audit: type=1400
audit(1424792041.549:3572): avc: denied { entrypoint } for pid=19015
comm="docker" path="/var/lib/docker/init/dockerinit-1.5.0-dev" dev="sda2"
ino=134594 scontext=system_u:system_r:spc_t:s0
tcontext=system_u:object_r:docker_var_lib_t:s0 tclass=file permissive=0
Feb 24 09:34:01 naruto kernel: [605832.429083] audit: type=1300
audit(1424792041.549:3572): arch=c000003e syscall=59 success=no exit=-13
a0=c208b05290 a1=c208602500 a2=c2085ceb20 a3=0 items=0 ppid=7465 pid=19015
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=4294967295 comm="docker" exe="/usr/bin/docker"
subj=system_u:system_r:docker_t:s0 key=(null)
Feb 24 09:34:01 naruto kernel: [605832.429110] audit: type=1327
audit(1424792041.549:3572):
proctitle=2F7573722F62696E2F646F636B6572002D64002D2D73656C696E75782D656E61626C6564
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years
[Bug 1203811] New: update to go1.4 :: for etcd requirement
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1203811
Bug ID: 1203811
Summary: update to go1.4 :: for etcd requirement
Product: Fedora
Version: 20
Component: golang
Assignee: vbatts(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,
lemenkov(a)gmail.com, renich(a)woralelandia.com, s(a)shk.io,
vbatts(a)redhat.com
Since golang is forward compatible, all applications that build with go1.3.3
will stay compatible. But allow upstream requirements of go1.4 to be satisfied.
https://github.com/coreos/etcd/issues/2524
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years
[Bug 1192742] New: Fix DWARF for variable references
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1192742
Bug ID: 1192742
Summary: Fix DWARF for variable references
Product: Fedora
Version: rawhide
Component: golang
Assignee: vbatts(a)redhat.com
Reporter: jan.kratochvil(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: 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
Created attachment 991800
--> https://bugzilla.redhat.com/attachment.cgi?id=991800&action=edit
A bit hacky fix
Description of problem:
https://sourceware.org/gdb/wiki/GoDebugging#golang_Wrong_DW_TAG_variable
golang provides &name variable names and the DWARF interface uses one more
pointer than in the source.
Version-Release number of selected component (if applicable):
golang-1.4.1-1.fc22.x86_64
How reproducible:
Always.
Steps to Reproduce:
-------------------
package main
func main () {
var i int
ip:=&i
ipp:=&ip
go func() {
**ipp++
}()
}
-------------------
Actual results:
(gdb) b 8
(gdb) r
(gdb) p i
No symbol "i" in current context.
(gdb) p &i
No symbol "i" in current context.
(gdb) p '&i'
Invalid character constant.
(gdb) p ' &i'
$1 = (int *) 0xc20800a080
(gdb) p *' &i'
$2 = 0
(gdb) p ' &ip'
$3 = (int **) 0xc20803a000
(gdb) p *' &ip'
$4 = (int *) 0xc20800a080
(gdb) p **' &ip'
$5 = 0
(gdb) p ' &ipp'
$6 = (int ***) 0xc20803a008
(gdb) p *' &ipp'
$7 = (int **) 0xc20803a000
(gdb) p **' &ipp'
$8 = (int *) 0xc20800a080
(gdb) p ***' &ipp'
$9 = 0
Expected results:
(gdb) b 8
(gdb) r
(gdb) p i
$1 = (int &) @0xc20800a080: 0
(gdb) p ip
$2 = (int *&) @0xc20803a000: 0xc20800a080
(gdb) p *ip
$3 = 0
(gdb) p ipp
$4 = (int **&) @0xc20803a008: 0xc20803a000
(gdb) p *ipp
$5 = (int *) 0xc20800a080
(gdb) p **ipp
$6 = 0
(gdb) whatis i
type = int &
(gdb) whatis ip
type = int *&
(gdb) whatis ipp
type = int **&
Additional info:
But you said golang upstream is writing some new linker so maybe this hack is
not much relevant for upstream. DW_AT_name of the reference types is IMO
incorrect but I do not think it matters much for GDB; for 'ipp' with this patch
there is:
<fe78> DW_AT_name : &(***int)
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years
[Bug 1200899] New: F21 has newer NVR than F22
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1200899
Bug ID: 1200899
Summary: F21 has newer NVR than F22
Product: Fedora
Version: 22
Component: docker-io
Severity: low
Assignee: lsm5(a)redhat.com
Reporter: jpopelka(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
F21 contains docker-io-1.5.0-1.fc21 (or docker-io-1.5.0-2.fc21 in
updates-testing) while there's still docker-io-1.4.1-27.git76baa35.fc22 in F22
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years
[Bug 1186669] New: Failed to start Docker Application Container Engine.
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1186669
Bug ID: 1186669
Summary: Failed to start Docker Application Container Engine.
Product: Fedora
Version: 21
Component: docker-io
Severity: high
Assignee: lsm5(a)redhat.com
Reporter: bugzilla.redhat.com(a)trancecode.co.uk
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
Created attachment 985059
--> https://bugzilla.redhat.com/attachment.cgi?id=985059&action=edit
grep -i 'docker' /var/log/audit/audit.log | tail
Description of problem:
I yum-updated to F21 latest and now docker service fails to start on boot.
This update included reboot to new kernel 3.18
[root@vm117 ~]# uname -a
Linux vm117 3.18.3-201.fc21.x86_64 #1 SMP Mon Jan 19 15:59:31 UTC 2015 x86_64
x86_64 x86_64 GNU/Linux
Maybe this could be related to the other new warning that I see in
joutnalctl -b
SELinux is preventing sm-notify from write access on the file nlm_end_grace.
For complete SELinux messages. run sealert
and
Dependency failed for Network Manager Wait Online.
Which I assume is new with 3.18 since web search found this:
https://www.kernel.org/pub/linux/utils/nfs-utils/1.3.1/1.3.1-Changelog
I don't see anything notable in /var/log/messages
Will attach a grep of /var/log/audit/audit.log
Version-Release number of selected component (if applicable):
[root@vm117 ~]# yum info docker-io.x86_64
Loaded plugins: langpacks
Installed Packages
Name : docker-io
Arch : x86_64
Version : 1.4.1
Release : 5.fc21
Size : 19 M
Repo : installed
>From repo : updates
How reproducible:
100% Service Fails to start on every boot.
Steps to Reproduce:
1. Reboot Fedora
2. systemctl status docker.service
3.
Actual results:
Expected results:
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years