[Bug 1184257] New: missing debug info
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1184257
Bug ID: 1184257
Summary: missing debug info
Product: Fedora
Version: rawhide
Component: etcd
Assignee: lacypret(a)gmail.com
Reporter: jan.kratochvil(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, lsm5(a)redhat.com,
walters(a)redhat.com
Created attachment 982040
--> https://bugzilla.redhat.com/attachment.cgi?id=982040&action=edit
etcd.spec patch
Description of problem:
Current etcd.rpm contains neither debug info embedded nor separate
etc-debuginfo.rpm.
Version-Release number of selected component (if applicable):
etcd-2.0.0-1.rc1.fc22.x86_64 (not yet in Koji - that's Bug 1176138)
How reproducible:
Always
Steps to Reproduce:
yum install etcd
debuginfo-install etcd
$ readelf -wil /usr/lib/debug/usr/bin/etcd.debug
Actual results:
readelf: Error: '/usr/lib/debug/usr/bin/etcd.debug': No such file
$ readelf -wil /usr/bin/etcd # does not show anything anyway
Expected results:
Raw dump of debug contents of section .debug_line:
[...]
Contents of the .debug_info section:
[...]
Additional info:
Sure the goal is GDB, not readelf. But readelf is more foolproof.
Patch follows the debuginfo rules I have just updated at:
https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FGo&diff=401...
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years
[Bug 1191438] New: docker-io-1.5.0 is available
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1191438
Bug ID: 1191438
Summary: docker-io-1.5.0 is available
Product: Fedora
Version: rawhide
Component: docker-io
Keywords: FutureFeature, Triaged
Assignee: lsm5(a)redhat.com
Reporter: upstream-release-monitoring(a)fedoraproject.org
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
Latest upstream release: 1.5.0
Current version/release in Fedora Rawhide: 1.4.1-27.git76baa35.fc22
URL: https://github.com/docker/docker/releases
Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy
More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring Soon this service
will be implemented by a new system: https://release-monitoring.org/
It will require to manage monitored projects via a new web interface. Please
make yourself familiar with the new system to ease the transition.
--
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 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