Bug 1061322
Summary: | systemd doesn't automatically restart rsyslog | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Tomas Heinrich <theinric> |
Component: | rsyslog | Assignee: | Tomas Heinrich <theinric> |
Status: | CLOSED ERRATA | QA Contact: | Marek Marusic <mmarusic> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 7.0 | CC: | btotty, cww, dapospis, fweimer, ksrot, mmarusic, mschmidt, pmutha, pvrabec, ssahani |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | 799331 | Environment: | |
Last Closed: | 2015-11-19 14:29:34 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Tomas Heinrich
2014-02-04 15:56:18 UTC
I was asked to consider this change for RHEL, hence reopening. I can only see automatic restart functionality useful in the case of a random crash (Restart=on-abort). Even in that case, this can lead to destruction of the data required for analysis of the crash or cause a restart & crash loop. The later perhaps can be managed employing some of systemd's directives (StartLimitBurst=, StartLimitInterval=, ...). So, is this behavior really desirable? (In reply to Tomas Heinrich from comment #1) > So, is this behavior really desirable? All I can say that it is really, really annoying when you're doing forensics and the syslog daemon was not running for extended periods of time because it was killed by the OOM killer or some other mishap. I guess the potential benefits outweigh the potential drawbacks. Though this is a change in behavior, it shouldn't be an excessively big one for a .2 release. I see a lot of upside for adding the automatic ability for rsyslog to automatically restart. For example, why else are you running rsyslog unless you want to capture critical log messages? Sometimes things go bad and a service like rsyslog is unintentionally killed and this make the support process very difficult if no logging information is captured during that period. If you want to troubleshoot an issue and you have lost your logging during that period, then you essentially have nothing to go on. If you don't want logging, then don't enable the service to run on the system. If you do want logging, then it would seem that you wouldn't want a bug or some rogue process killing rsyslogd. Although, we do have to consider any side effects of implementing a rsyslog auto-restart. For example, is there a potential for exploit of a auto-restarting service? Possibly. But, in the case that you are using a daemon like auditd, you might have a better change of catching malicious attempts for process execution or other unwanted behavior. If this is implemented, it should be clearly stated in the man pages and easy to change if it is unwanted by a systems administrator. We could also look at setting a counter or some type of time interval in case of a repeated rsyslog crash. You wouldn't want rsyslog to crash and come back up hundreds or thousands of times on a production server. (In reply to Bryan Totty from comment #8) Thank you Bryan. We'll leverage systemd's auto-restart functionality, thus it's easy for us to turn it on and for anybody to change it. systemd, by default, also prevents an excessive number of restarts to happen in a short time. (In reply to Bryan Totty from comment #8) > I see a lot of upside for adding the automatic ability for rsyslog to > automatically restart. > > For example, why else are you running rsyslog unless you want to capture > critical log messages? > > Sometimes things go bad and a service like rsyslog is unintentionally killed > and this make the support process very difficult if no logging information > is captured during that period. If you want to troubleshoot an issue and you > have lost your logging during that period, then you essentially have nothing > to go on. If you don't want logging, then don't enable the service to run on > the system. If you do want logging, then it would seem that you wouldn't > want a bug or some rogue process killing rsyslogd. Unless journald is configured as volatile, no logs will be missed if journald is configured as persistent. rsyslog just pull the data from the journal. Logs are always available with journal if configured to be persistent. (In reply to Susant Sahani from comment #12) > Unless journald is configured as volatile, no logs will be missed if journald > is configured as persistent. rsyslog just pull the data from the journal. > Logs are always available with journal if configured to be persistent. In el7, the storage for journald defaults to 'auto'. Since /var/log/journal doesn't exist by default, the storage is effectively 'volatile'. 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://rhn.redhat.com/errata/RHBA-2015-2173.html |