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"?

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.

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

(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.

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.

(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?

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.

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.

Similar problem in 7.3? 

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