RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1031163 - dhclient fails to start using virt-sandbox-service
Summary: dhclient fails to start using virt-sandbox-service
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt-sandbox
Version: 7.0
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Daniel Berrangé
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-15 18:37 UTC by Martin Jenner
Modified: 2019-02-14 02:22 UTC (History)
1 user (show)

Fixed In Version: libvirt-sandbox-0.5.0-7.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 09:40:04 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Martin Jenner 2013-11-15 18:37:06 UTC 
Description of problem: Using virt-sandbox-service I specified 'dhcp' libvirt-sandbox should have started a dhclient instance in the container

Version-Release number of selected component (if applicable):

RHEL 7 beta compose - RHEL-7.0-20131107.1
libvirt-sandbox-0.5.0-5.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. this is how I setup the network I used for the container.

cat << EOF > virbr1.xml
<network>
<name>virbr1</name>
<forward mode='nat'/>
<bridge name='virbr1' stp='on' delay='0'/>
<ip address='192.168.123.1' netmask='255.255.255.0'>
  <dhcp>
    <range start='192.168.123.2' end='192.168.123.200' />
    <host mac='52:54:00:ec:b6:c1' name='vm1' ip='192.168.123.201'/>
    <host mac='52:54:00:ec:b6:c2' name='vm2' ip='192.168.123.202'/>
    <host mac='52:54:00:ec:b6:c3' name='vm3' ip='192.168.123.203'/>
    <host mac='52:54:00:ec:b6:c4' name='vm4' ip='192.168.123.204'/>
    <host mac='52:54:00:ec:b6:c5' name='vm5' ip='192.168.123.205'/>
    <host mac='52:54:00:ec:b6:c6' name='vm6' ip='192.168.123.206'/>
    <host mac='52:54:00:ec:b6:c7' name='vm7' ip='192.168.123.207'/>
    <host mac='52:54:00:ec:b6:c8' name='vm8' ip='192.168.123.208'/>
    <host mac='52:54:00:ec:b6:c9' name='vm9' ip='192.168.123.209'/>
  </dhcp>
</ip>
</network>
EOF

virsh net-define virbr1.xml
virsh net-autostart virbr1
virsh net-start virbr1
virsh net-list
virsh net-dumpxml virbr1


cat << EOF >> /etc/hosts

192.168.123.201 vm1
192.168.123.202 vm2
192.168.123.203 vm3
192.168.123.204 vm4
192.168.123.205 vm5
192.168.123.206 vm6
192.168.123.207 vm7
192.168.123.208 vm8
192.168.123.209 vm9

EOF

2. start a container using network virbr1

virt-sandbox-service create --copy -N dhcp,mac=52:54:00:ec:b6:c2,source=virbr1 --unitfile crond.service vm2


Actual results:

dhclient did not start, this was checked as follows

virt-sandbox-service execute vm2 -- /bin/sh

h-4.2# ip addr show eth0
42: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
qlen 1000
    link/ether 52:54:00:ec:b6:c2 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5054:ff:feec:b6c2/64 scope link
       valid_lft forever preferred_lft forever

- let's have a look at the processes

sh-4.2# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 10:10 ?        00:00:00 /lib/systemd/systemd --unit
mult
root        13     1  0 10:10 ?        00:00:00
/usr/lib/systemd/systemd-journal
root        14     1  0 10:10 ?        00:00:00 /usr/sbin/crond -n
root        16     0  0 10:16 ?        00:00:00 /bin/sh
root        18    16  0 10:18 ?        00:00:00 ps -ef

- dhclient is not running ?

I now ran dhclient manually inside the contianer and the network started

Expected results:
dhclinet should be running and the network started.

Additional info:
Comment 2 Daniel Berrangé 2013-11-27 17:33:17 UTC 
strace shows that the dhclient process is dieing due to SIGHUP at some point in the container startup process. This only happens with systemd based containers, not generic ones.
Comment 3 Daniel Berrangé 2013-11-28 17:05:34 UTC 
commit ee930331002c677643a507acc106c0145525e746
Author: Daniel P. Berrange <berrange>
Date:   Thu Nov 28 17:03:12 2013 +0000

    Block SIGHUP when running dhclient
    
    The dhclient process we create is associated with the controlling
    terminal of the "init" process. When we systemd in a container
    one of the first things it does is disassociate itself from any
    controlling terminal. This causes other apps associated with
    that session to receive SIGHUP. This unfortunately kills off
    the dhclient process we spawned. We can't set the signal handler
    to SIG_IGN since glib2's spawn method will reset that. Instead
    we just block the SIGHUP signal entirely using a signal mask.
    
    Signed-off-by: Daniel P. Berrange <berrange>
Comment 5 Alex Jia 2013-12-03 02:50:45 UTC 
(In reply to Martin Jenner from comment #0)
> 2. start a container using network virbr1
> 
> virt-sandbox-service create --copy -N
> dhcp,mac=52:54:00:ec:b6:c2,source=virbr1 --unitfile crond.service vm2
> 

# virsh -c lxc:/// start vm2
Domain vm2 started

> 
> Actual results:
> 
> dhclient did not start, this was checked as follows
> 
> virt-sandbox-service execute vm2 -- /bin/sh
> 

sh-4.2# ip addr show eth0
460: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:ec:b6:c2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.123.202/24 brd 192.168.123.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:feec:b6c2/64 scope link 
       valid_lft forever preferred_lft forever
sh-4.2# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 10:45 ?        00:00:00 /lib/systemd/systemd --unit multi-user.target --log-target console --system
root        27     1  0 10:45 ?        00:00:00 /usr/lib/systemd/systemd-journald
root        34     1  0 10:45 ?        00:00:00 /usr/sbin/crond -n
dbus        50     1  0 10:45 ?        00:00:00 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
root        78     1  0 10:45 ?        00:00:00 /sbin/dhclient --no-pid eth0
root        79     0  0 10:45 pts/0    00:00:00 /bin/sh
root        81    79  0 10:45 pts/0    00:00:00 ps -ef

The 'dhcleint' is running and can get IP address automatically in the container, so move the bug to 'VERIFIED' status.

# rpm -q libvirt-sandbox libvirt kernel systemd
libvirt-sandbox-0.5.0-7.el7.x86_64
libvirt-1.1.1-13.el7.x86_64
kernel-3.10.0-0.rc7.64.el7.x86_64
systemd-206-7.el7.x86_64
Comment 7 Ludek Smid 2014-06-13 09:40:04 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.
Note You need to log in before you can comment on or make changes to this bug.