golang March 2015

golang@lists.fedoraproject.org

8 participants
437 discussions

[Bug 1046717] New: Cancel run or pull operation doesn't actually stop the ongoing task
by Red Hat Bugzilla 15 Apr '15

15 Apr '15

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.

1 9

[Bug 1087704] New: repetition of signal 21 with --sig-proxy and SIGSTOP of docker
by Red Hat Bugzilla 15 Apr '15

15 Apr '15

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.

1 13

[Bug 1087720] New: signal 27 (SIGPROF) not passed to container using --sig-proxy
by Red Hat Bugzilla 15 Apr '15

15 Apr '15

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.

1 17

[Bug 1166312] New: etcd unit should support command line options
by Red Hat Bugzilla 13 Apr '15

13 Apr '15

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.

1 4

[Bug 1166950] New: Unable to run "mysql" docker image on Fedora atomic due to selinux
by Red Hat Bugzilla 13 Apr '15

13 Apr '15

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.

1 5

[Bug 1195804] New: docker run fails on rawhide with setenforce 1
by Red Hat Bugzilla 09 Apr '15

09 Apr '15

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.

1 8

[Bug 1203811] New: update to go1.4 :: for etcd requirement
by Red Hat Bugzilla 06 Apr '15

06 Apr '15

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.

1 11

[Bug 1192742] New: Fix DWARF for variable references
by Red Hat Bugzilla 02 Apr '15

02 Apr '15

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.

1 8

[Bug 1200899] New: F21 has newer NVR than F22
by Red Hat Bugzilla 31 Mar '15

31 Mar '15

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.

1 7

[Bug 1186669] New: Failed to start Docker Application Container Engine.
by Red Hat Bugzilla 31 Mar '15

31 Mar '15

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.

1 15

← Newer
1
...
4
5
6
7
8
9
10
...
44
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang March 2015