Bug 1304062

I do see this message in the logs: Volume group "fedora_dhcp129-24" has insufficient free space (0 extents): 5 required.

I don't believe Docker in F23 "requires" free extents, or otherwise depends on LVM. Is this error message why the core dump is happening, or is it just an info message that is harmless?

And of course I forgot this important info:

$ rpm -q docker
docker-1.10.0-20.gitd3f4a34.fc24.x86_64

Vivek, looks like this is something for you.

(seems to work fine on my rawhide machine)

more info: docker-1.10.0-20.gitd3f4a34.fc24.x86_64 used docker-storage-setup commit#1c2b95b

I think this is a docker issue. docker-storage-setup is just saying that it can't setup an lvm thin pool as there is not sufficient free space in root volume group. That means docker will use loop devices to setup thin pool. If docker is crashing after that, there is something wrong with docker.

Randy.

Do you see AVC's 

ausearch -m avc -ts recent


If you just run 

# docker daemon

Does this blow up?

Hello Dan!

The ausearch command did return some output, but it was ~10 minutes before I ran systemctl start docker so I don't think it's related. They all seem iptables related and look similar to this:

time->Wed Feb  3 15:22:05 2016
type=AVC msg=audit(1454530925.689:444): avc:  denied  { read write } for  pid=1218 comm="ip6tables" path=2F746D702F6666694D66306F784A202864656C6574656429 dev="tmpfs" ino=33197 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:firewalld_tmpfs_t:s0 tclass=file permissive=0

If I run docker daemon directly, it seg faults:

$ sudo docker daemon
Segmentation fault

If I re-run ausearch after this (or after another invocation with systemctl) it says <no matches> so I don't believe this is selinux related.

Thanks for the tips, and I'm happy to help more if I can. I'm bowlofeggs on Freenode.

Does not look like an SELinux issue.

Randy did you have containers/images stored in /var/lib/docker?

Seems to be something to do with your content under /var/lib/docker.   If you have nothing of value there, I would run rm -rf /var/lib/docker and then see if you can start the docker daemon with systemctl start docker.


Another idea would be to make sure there is no problem with your install

dnf -y reinstall docker

Since this is the first time docker has been installed on this particular system, there is nothing in /var/lib/docker:

$ sudo ls -lah /var/lib/docker/                                                         
total 8.0K
drwxr-xr-x.  2 root root 4.0K Jan 29 12:51 .
drwxr-xr-x. 34 root root 4.0K Feb  2 13:47 ..

I saw that there was an update available for Docker in Rawhide, so I updated but the problem remains:

$ rpm -q docker
docker-1.10.0-21.gitd3f4a34.fc24.x86_64

Even though the update probably was sufficient, I went ahead and did the reinstall as well just in case that causes different script to run or something, and that also did not solve the seg fault.

Anything else I can look at?

Dan and I have done a bit of sideline chatting about this issue, as he nor anyone else is able to reproduce this problem. I also tried to reproduce it and was not able to. However, it just occurred to me that there was one difference that might matter between my reproduction machine and the machine that had the issue. The original machine I reported this issue about runs Fedora Rawhide Server, and is a kvm guest. The machine I attempted to reproduce it on was an OpenStack Fedora 23 Cloud image that I then used dnf to upgrade to Rawhide. Could Fedora Server vs. Cloud be the difference that matters? Dan, which type(s) of environment(s) did you attempt to reproduce this in?

(In reply to Randy Barlow from comment #11)
> Dan and I have done a bit of sideline chatting about this issue, as he nor
> anyone else is able to reproduce this problem. I also tried to reproduce it
> and was not able to. However, it just occurred to me that there was one
> difference that might matter between my reproduction machine and the machine
> that had the issue. The original machine I reported this issue about runs
> Fedora Rawhide Server, and is a kvm guest. The machine I attempted to
> reproduce it on was an OpenStack Fedora 23 Cloud image that I then used dnf
> to upgrade to Rawhide. Could Fedora Server vs. Cloud be the difference that
> matters? Dan, which type(s) of environment(s) did you attempt to reproduce
> this in?

I think that might be caused by BZ1304591, I'm on it right now. 

Could you provide output of lscpu in meantime? (or more specifically does your cpu support AVX?)

Hello Jakub!

I do not see the string AVX (or avx) in the output of lscpu. Here is lscpu on the guest that has this issue:

$ ssh boole lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             4
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 44
Model name:            Westmere E56xx/L56xx/X56xx (Nehalem-C)
Stepping:              1
CPU MHz:               2128.000
BogoMIPS:              4256.00
Hypervisor vendor:     KVM
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              4096K
NUMA node0 CPU(s):     0-3
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm constant_tsc rep_good nopl pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lahf_lm arat

Here is lscpu on the host:

$ lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 44
Model name:            Intel(R) Xeon(R) CPU           E5606  @ 2.13GHz
Stepping:              2
CPU MHz:               1197.000
CPU max MHz:           2128.0000
CPU min MHz:           1197.0000
BogoMIPS:              4255.91
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              8192K
NUMA node0 CPU(s):     0-3
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm arat epb dtherm tpr_shadow vnmi flexpriority ept vpid

This matches the known golang ABI issue.

*** This bug has been marked as a duplicate of bug 1304591 ***