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 1212883 - dhclient (via network-functions) empties resolv.conf because of grep
Summary: dhclient (via network-functions) empties resolv.conf because of grep
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: initscripts
Version: 7.1
Hardware: Unspecified
OS: Linux
Target Milestone: rc
: ---
Assignee: initscripts Maintenance Team
QA Contact: qe-baseos-daemons
: 1208050 1279393 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2015-04-17 15:08 UTC by Felix Hassert
Modified: 2019-08-15 04:29 UTC (History)
9 users (show)

Fixed In Version: initscripts-9.49.25-1.el7
Doc Type: Bug Fix
Doc Text:
Due to a change behavior of the grep command, the resolv.conf file was always deleted. The underlying source code has been modified to fix this bug, and the intended behavior has been restored.
Clone Of:
Last Closed: 2015-11-19 11:29:35 UTC
Target Upstream Version:

Attachments (Terms of Use)
patch to fix network-functions (410 bytes, patch)
2015-04-17 15:08 UTC, Felix Hassert
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
CentOS 8490 0 None None None Never
Red Hat Knowledge Base (Solution) 1433223 0 None None None Never
Red Hat Product Errata RHBA-2015:2134 0 normal SHIPPED_LIVE initscripts bug fix update 2015-11-19 10:18:39 UTC

Description Felix Hassert 2015-04-17 15:08:10 UTC
Created attachment 1015631 [details]
patch to fix network-functions

What happened before?

Originally, I encountered this bug in CENTOS 7.1 and filed it there: http://bugs.centos.org/view.php?id=8490

The centos guys have sent me over here to report it, because they cannot address it directly.


Description of problem:

Starting with CentOS 7.1 change_resolv_conf() (in /etc/sysconfig/network-scripts/network-functions) deletes all rows except options from /etc/resolv.conf, when resolv.conf options are configured (RES_OPTIONS=...)

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

$ rpm -qf /etc/sysconfig/network-scripts/network-functions

How reproducible:

I use CentOS 7 in a vagrant image that I build with packer from the CentOS minimal isos. But this should be reproducible in other setups, too.

To workaround a DNS bug in virtualbox I have a resolve option configured:

$ cat /etc/sysconfig/network
# Created by anaconda

One of the network interfaces uses DHCP. Thus, dhclient is triggered upon boot/reboot. This is printed in /var/log/messages:

Apr 17 07:47:49 localhost dhclient[789]: DHCPDISCOVER on enp0s3 to port 67 interval 3 (xid=0x52fcbf18)
Apr 17 07:47:49 localhost dhclient[789]: DHCPREQUEST on enp0s3 to port 67 (xid=0x52fcbf18)
Apr 17 07:47:49 localhost dhclient[789]: DHCPOFFER from
Apr 17 07:47:49 localhost dhclient[789]: DHCPACK from (xid=0x52fcbf18)
Apr 17 07:47:49 localhost kernel: floppy0: no floppy controllers found
Apr 17 07:47:51 localhost NET[834]: /usr/sbin/dhclient-script : updated /etc/resolv.conf
Apr 17 07:47:51 localhost dhclient[789]: bound to -- renewal in 43148 seconds.
Apr 17 07:47:51 localhost network: Determining IP information for enp0s3... done.
Apr 17 07:47:51 localhost network: [ OK ]

After "updated /etc/resolv.conf" has happened, the resolv.conf contains only options.

Actual results:

$ cat /etc/resolv.conf 
options single-request-reopen

Expected result:

$ cat /etc/resolv.conf 
; generated by /usr/sbin/dhclient-script
search .....
options single-request-reopen

Additional info:

Digging into /usr/sbin/dhclient-script and /etc/sysconfig/network-scripts/network-functions, we could see that the DHCP response was correct. dhclient-script puts the proposed resolv.conf into a tempfile and calls change_resolv_conf() with the tmpfile as $1.

I step through change_resolv_conf() to explain the problem.

At first the options from the _existing_ /etc/resolv.conf are saved. (This is why this bug may only appear after a reboot and not on the first boot).

    s=$(/bin/grep '^[\ \ ]*option' /etc/resolv.conf 2>/dev/null);
    if [ "x$s" != "x" ]; then

Options are grepped into $s. If there are options a newline is appended to $s. -> This is the cause of the bug.

In my case the function receives only one parameter (the tmpfile), so I did not examine the if block. We step into the else block:

    elif [ $# -eq 1 ]; then
       if [ "x$s" != "x" ]; then
          s="$s"$(/bin/grep -vF "$s" $1);
          s=$(cat $1);

If options are not empty, the result are the options ($s) followed by the tmp resolv.conf ($1) that is cleared from exactly the existing options.

This grep returns nothing in CentOS 7.1 (grep 2.20) and the expected resolv.conf w/o options in CentOS 7.0 (grep 2.16).

I assume that grep 2.19 has introduced this new behaviour, that was actually a bug fix: 
http://savannah.gnu.org/forum/forum.php?forum_id=7988 [^]

" grep no longer mishandles an empty pattern at the end of a pattern list. [bug introduced in grep-2.5]"

This is exactly what has happened here. The $s contains one or more option lines followed by a redundant newline. The documentation of grep -F says:

" -F, --fixed-strings PATTERN is a set of newline-separated fixed strings"

The appended newline causes an empty string to be interpreted as a fixed string pattern. The empty string matches every line and -v removes all of them from the output.

I have attached a conservative patch for network-functions that avoids the bug in the else-block (change_resolv_conf /tmp/foo). A better fix would be to not append the \n in the first place. But as I don't know when change_resolv_conf is called with more parameters (if-block), I could not check if that would brake anything else.

Comment 2 Lukáš Nykrýn 2015-04-20 07:46:13 UTC
This should be already fixed in upstream and it is planned to be backport in rhel-7.2


Comment 4 Lukáš Nykrýn 2015-05-06 11:58:26 UTC
*** Bug 1208050 has been marked as a duplicate of this bug. ***

Comment 6 John DeSantis 2015-08-06 12:34:15 UTC

Looking at the documented URL's concerning this bug, I don't see any reference to RHEL 6.x.  I can confirm that in our environment running SL 6.x, we experienced this bug.  

Since the 6.x series hasn't been mentioned, is there any plan on backporting these changes?   I'd prefer to not apply an empty make_resolv_conf() function via a hook, nor deny grep upgrades via excludes.

John DeSantis

Comment 7 Lukáš Nykrýn 2015-08-06 12:44:14 UTC
This patch should be included in 9.03.49 version of rhel6 initscripts


Comment 8 John DeSantis 2015-08-06 12:49:19 UTC
(In reply to Lukáš Nykrýn from comment #7)
> This patch should be included in 9.03.49 version of rhel6 initscripts
> https://git.fedorahosted.org/cgit/initscripts.git/commit/?h=rhel6-
> branch&id=ecc64049caf281e5f18fd6996f3716c83aacdad3

Thank you for such a quick response!

John DeSantis

Comment 10 Jiri Popelka 2015-11-11 17:26:19 UTC
*** Bug 1279393 has been marked as a duplicate of this bug. ***

Comment 11 errata-xmlrpc 2015-11-19 11:29:35 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.