1396840 – Missing files in /etc/sysconfig

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 1396840 - Missing files in /etc/sysconfig

Summary: Missing files in /etc/sysconfig

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	chrony
Sub Component:
Version:	7.2
Hardware:	Unspecified
OS:	Unspecified
Priority:	high
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Miroslav Lichvar
QA Contact:	Karel Volný
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2016-11-20 20:22 UTC by Thomas Spear
Modified:	2017-08-01 16:20 UTC (History)
CC List:	3 users (show)
Fixed In Version:	chrony-3.1-1.el7
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2017-08-01 16:20:39 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2017:1908	0	normal	SHIPPED_LIVE	chrony bug fix and enhancement update	2017-08-01 17:54:45 UTC

Description Thomas Spear 2016-11-20 20:22:35 UTC

Description of problem:
I have specified in my chrony.conf file the following:

bindcmdaddress ::1

I have validated that no other bind* directives exist in the config file, and it does not appear that /etc/chrony.conf.d is a valid directory for specifying additional config files to load in, so there should be no other configs anywhere.

Yet, after restarting chrony on my server, I find that in netstat -pln, the host is still bound to both loopback interfaces (IPv4 and IPv6)

[root@jump keys]# netstat -pln |grep :323
udp        0      0 127.0.0.1:323           0.0.0.0:*                           25813/chronyd
udp6       0      0 ::1:323                 :::*                                25813/chronyd


Version-Release number of selected component (if applicable):
chrony-2.1.1-1.el7.centos.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Comment out the "bindcmdaddress 127.0.0.1" entry in the default /etc/chrony.conf file
2. Save the file
3. Restart chronyd
4. Check netstat as per the above example output

Actual results:
Chrony binds to both IPv4 and IPv6 addresses

Expected results:
Chrony should bind to only the IPv6 address

Additional info:
This is a VM I'm using to test IPv6 in my environment. Thusly, I'm looking to disable IPv4 binds wherever possible before looking into any potential sysctl parameters to completely disable IPv4. This is blocking that effort.

Comment 1 Miroslav Lichvar 2016-11-21 06:58:22 UTC

The IPv4 command port can be disabled by adding the -6 option on the chronyd command line (OPTIONS="-6" in /etc/sysconfig/chronyd). That will disable also the IPv4 NTP server port. Does it work for you?

Comment 2 Thomas Spear 2016-11-21 07:36:27 UTC

Indeed, that does work, however I had to create the file.

There's no mention in manpages or on RH Access that that file will be read in if it exists, and unlike in SysV setups where you could easily find out by catting out the init script, anyone new to systemd isn't necessarily going to know what file to cat in order to find out if it will be loaded or not.

Would it be possible to get an empty/dummy file (OPTIONS="") placed in /etc/sysconfig during install of the package?

Comment 3 Miroslav Lichvar 2016-11-21 07:51:50 UTC

I think having no file in /etc/sysconfig is an approach recommended by systemd and is used by other packages in the distribution. Maybe it would be better to properly document it on the distribution level instead of adding the (empty) files back.

Comment 5 Lukáš Nykrýn 2016-12-06 15:21:17 UTC

(In reply to Miroslav Lichvar from comment #3)
> I think having no file in /etc/sysconfig is an approach recommended by
> systemd and is used by other packages in the distribution. Maybe it would be
> better to properly document it on the distribution level instead of adding
> the (empty) files back.

I don't think that we ever suggested to not ship a file. We have suggested that this way of a configuring service should go away. Every service should has its own options in its regular configuration file.

Also /etc/sysconfig directory is quite redhat-specific, debian for example did something similar with /etc/default, so these environment files are a problem to upstream.

So in general, if our customers has a such problem we really should push the upstream to implement all those settings to the regular configuration file. 

Anyway, I don't think that this should go to documentation, those environment files could be anywhere and the options in it are not standardized. We should really eradicate this type of configuration instead. So let's start with chrony :-)

> There's no mention in manpages or on RH Access that that file will be read
> in if it exists, and unlike in SysV setups where you could easily find out
> by catting out the init script

Well you can grep the unit file for EnvironmentFile
or 
[lnykryn@notas system]$ systemctl cat nfs-lock.service | grep Environ
EnvironmentFile=-/run/sysconfig/nfs-utils

Comment 6 Thomas Spear 2016-12-21 18:22:25 UTC

Ok, so /run/sysconfig/nfs-utils is the proper environment file to use?

Given that /run is not persistent, what is the proper way to make this setting stick across reboots?

Comment 7 Miroslav Lichvar 2017-01-25 15:41:25 UTC

(In reply to Lukáš Nykrýn from comment #5)
> Anyway, I don't think that this should go to documentation, those
> environment files could be anywhere and the options in it are not
> standardized.

The documentation could describe how to find these environment files.

> We should really eradicate this type of configuration instead.
> So let's start with chrony :-)

That probably won't work for chrony. There are options like -r and -R that should be set only when the service is restarted, and options like -s that should be set only on the first start during boot. Modifying chrony.conf before each (re)start would be impractical. Unfortunately systemd doesn't support options specific to restart, but with other init systems that may be possible.

Comment 8 Thomas Spear 2017-01-25 16:00:03 UTC

Specifically to this problem, I honestly feel that a documentation update would be fine while you work out what to do going forward internally.

Should I go ahead and file a new bug and close this one?

Comment 9 Miroslav Lichvar 2017-01-25 16:26:51 UTC

I think we can keep this bug open for the suggestion to include in the package the /etc/sysconfig/chronyd config file, so admins can at least see it listed in the output of the "rpm -qc" command.

If you think the documentation should explain the environment files in the distribution, please file a new bug.

Comment 12 errata-xmlrpc 2017-08-01 16:20:39 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.

https://access.redhat.com/errata/RHBA-2017:1908

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