Description of problem:

qpidd does not listen to 0.0.0.0 if none of the physical network devices
has an IPv4 assigned.
Because network.target is only listed as a "Requires" in the qpidd.service file, qpidd and network service may be started at the same time.
The problem is that if IPv4 on network devices are obtained through DHCP, qpidd may be started before IPv4 are assigned and it ends up not listening to 0.0.0.0 at boot.  

Version-Release number of selected component:
Tested on Version 0.24 Release 3.fc19.1

How reproducible:
The bugs does not show up if DHCP server are fast enough to respond before qpidd checks for IPv4 on physical interfaces.

Steps to Reproduce the behaviour of qpidd:
1. systemctl stop qpidd.service
2. ip a del <ipaddress>/<netmask> dev <physical device>
3. systemctl start qpidd.service
4. netstat -ntupa | grep qpi

Actual results:
tcp6       0      0 :::5672                 :::*                    LISTEN      388/qpidd           

Expected results:
tcp        0      0 0.0.0.0:5672            0.0.0.0:*               LISTEN      388/qpidd           
tcp6       0      0 :::5672                 :::*                    LISTEN      388/qpidd           


Steps to Reproduce the bug:
1. Set up a physical device to use DHCP at boot
2. Set up a slow DHCP server or slow network
3. install qpid-cpp-server
4. reboot
5. netstat -ntupa | grep qpi

I understand that mocking a slow DHCP server is not an easy task. I hit the bug in a busy test environment while starting 3 virtual machines with 2 physical device each at the same time.


Additional info:
I'm not sure why qpidd checks for IPv4 availability and if this beahaviour should be corrected, but a fast fix to this could be to set network.target as a "After" not "Requires" option on qpidd.service file. In this way qpidd have to wait for network service to finish.
This is the workaround I used and it worked 100% of the time.