Bug 1201966

Summary:	rsyslog.conf overwritten by default on reboot
Product:	Red Hat Enterprise Linux 6	Reporter:	paul <paullee0>
Component:	rsyslog	Assignee:	Tomas Heinrich <theinric>
Status:	CLOSED WORKSFORME	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	6.4	CC:	paullee0, pvrabec, sgilson, theinric
Target Milestone:	rc
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-07-18 22:41:21 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1172231

Description paul 2015-03-14 03:38:17 UTC

Description of problem:
The /etec/rsyslog.conf is restored to a default template upon system reboot.  Any changes to that file is lost after that reboot.

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


How reproducible:


Steps to Reproduce:
1. Make changes to the /etc/rsyslog.conf
2. Restart the rsyslogd (or not)
3. Reboot the system


Actual results:
All changes to that files are lost, only a default template configuration file is found at /etc.

Expected results:
Changes to that files are persisted.

Additional info:

Comment 2 Tomas Heinrich 2015-03-16 16:39:16 UTC

Hello,

(In reply to paul from comment #0)
> Description of problem:
> The /etec/rsyslog.conf is restored to a default template upon system reboot.
> Any changes to that file is lost after that reboot.

> Steps to Reproduce:
> 1. Make changes to the /etc/rsyslog.conf
> 2. Restart the rsyslogd (or not)
> 3. Reboot the system

I'm not able to reproduce the symptoms you've described.
Which version of rsyslog are you using?

I don't think that, as part of the rsyslog package, there is a facility to restore configuration files upon reboots.
Therefore it seems more probable that this problem is rooted in a different component or a local customization.

Could you also post the output of "rpmverify rsyslog"?

Comment 3 paul 2015-03-17 16:18:07 UTC

Thanks.

1. version : rsyslog-5.8.10-9

2. > rpmverify rsyslog
   S.5....T.  c /etc/rsyslog.conf

3. If the system is forced to electrically power off / reboot rather than through commandline, the changed rsyslog.conf is kept over reboot.

4. I thought I found a similar report which was made some time ago like 2013 but can't find it again.

Comment 4 paul 2015-03-17 16:22:46 UTC

5.  Is this Bug 767037 relevant?  https://bugzilla.redhat.com/show_bug.cgi?id=767037

Comment 5 Tomas Heinrich 2015-03-17 19:10:35 UTC

(In reply to paul from comment #4)
> 5.  Is this Bug 767037 relevant? 
> https://bugzilla.redhat.com/show_bug.cgi?id=767037

As there is very little information provided about your system (whether you actually use the ovirt-node component, which other products you use and whether there is any local customization), it's impossible to tell.

Comment 6 Stephen Gilson 2015-04-13 19:02:03 UTC

This issue needs to be described in the Release Notes for RHEL 6.7

Content Services needs your input to make that happen. 

Please complete the Doc Text text field for this bug by April 20 using the Cause, Consequence, Workaround, and Result model, as follows:

Cause — Actions or circumstances that cause this bug to occur on a customer's system

Consequence — What happens to the customer's system or application when the bug occurs?

Workaround (if any) — If a workaround for the issue exists, describe in detail. If more than one workaround is available, describe each one.

Result — Describe what happens when a workaround is applied. If the issue is completely circumvented by the workaround, state so. Any side effects caused by the workaround should also be noted here. If no reliable workaround exists, try to describe some preventive measures that help to avoid the bug scenario.

Comment 7 Tomas Heinrich 2015-04-13 22:30:17 UTC

(In reply to Stephen Gilson from comment #6)
> This issue needs to be described in the Release Notes for RHEL 6.7

Would you care to elaborate on why this needs to be part of the Release Notes?

Comment 8 paul 2015-12-19 03:51:42 UTC

Found the following:-

tuned/ktune restore the file at /var/run/tuned/ktune-cpuspeed.save 


I dig into this issue again, as recently the rsyslog can't be started upon bootup.

I found, when the /var.../ktune-cpuspeed.save file is restored to /etc/, it do not have the right SE context type to run and rsyslog fails to start upon bootup.


-rw-r--r--. root root system_u:object_r:tuned_var_run_t:s0 ktune-cpuspeed.save


Hope this helps someone.

Comment 9 Tomas Heinrich 2016-01-04 18:58:36 UTC

The symptoms you're seeing are not caused by the rsyslog package and hence can't be fixed in the rsyslog package.
You should think about which products you have installed assign this bug to the right component. Otherwise I don't see this getting any traction.

Comment 10 paul 2016-02-06 03:17:12 UTC

Similar problem in 7.3? 

https://bugzilla.redhat.com/show_bug.cgi?id=1268901