Red Hat Bugzilla – Bug 436866
RFE: RHEL5.3 - Option for sysklogd to not create log files if they do not already exist in /var/log/
Last modified: 2012-01-17 12:19:59 EST
Description of problem:
RFE Request for sysklogd
What is the exact nature of the problem trying to be solved with this request?
Add a flag to sysklogd to not create log files if they do not already exist
(adding legacy behaviour to current)
What, if any, business requirements are satisfied by this request? (What is the
use case context?)
Customer sometimes sees that syslog will open a file in /var/log/ prior to the
SAN being up (where the logs will be written), what happens is that / will fill
up, because the logs are being written to /, rather than the SAN mounted /var
List the functional requirement(s) for performing the action(s) that are not
presently possible. Please focus on describing the problem related requirements
without projecting any specific solution.
Each functional requirement must have clear acceptance criteria so Red Hat
understands what success looks like. If test cases can be provided this would be
even more ideal (bonus points for RHTS test cases).
This is more of a 'nice to have', there are work-arounds, this would be
relatively easy to implement, but this would of course be a deviation from
Syslog does not create log files that do not currently exist in /var/log
What is the desired release vehicle to satisfy these requirements? Major release
Please justify with reference to the release vehicle policy described in the
RHEL Inclusion Criteria wiki page
RHEL 5.3 ideally (sounds like a relatively small and non-intrusive change)
RHEL 6 would work as well.
What package(s) are affected by this RFE? (List "new" if new technology is
likely to be required)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
I would recommend to start sysklogd after the SAN is up
I'm sorry for terse comment. I'm not sure what desired behaviour is.
If syslog doesn't create log files, where should it write messages? Isn't the
situation same like if it wasn't even started?
Another option would be to let it be as it is, and HUP syslog when SAN gets up.
Nothing will be lost. What do you think?
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
This enhancement request was evaluated by Red Hat Product Management for inclusion a Red Hat Enterprise Linux minor update release.
Red Hat does not currently plan to provide this enhanced functionality in a Red Hat Enterprise Linux minor update for currently deployed products.
With the goal of minimizing risk of change for deployed systems, and in response to customer and partner requirements, Red Hat takes a conservative approach when evaluating enhancements for inclusion in minor updates for currently deployed products. The primary objectives of update releases are to enable new hardware platform support and to resolve critical defects.
For more information on Red Hat Enterprise Linux maintenance policies, please consult: http://www.redhat.com/security/updates/errata/
Red Hat values your feedback and will take this enhancement request into consideration for future major releases of Red Hat Enterprise Linux.
Created attachment 370072 [details]
this is a patch that implements behaviour that might satisfy the customer.
It provides new option, that will cause sysklogd stop creating log fixes. When there is a new message for missing log file, sysklogd checks if the file exists. If it exists, sysklogd will start logging into this log file. Otherwise it will emit syslog message (syslog.err) informing that log file doesn't exist. Sysklogd won't try to deliver any other message to this log file for 60seconds(timeout).
I would suggest to config sysklogd in a way that it will log syslog.err messages to admin visible place.
I would appreciate feedback from customer. If he likes this behaviour, we can try to push it to sysklogd upstream and rsyslog upstream too. There isn't such a thing in rsyslog. So if we push it into sysklogd, we will need to do the same for rsyslog.(RHEL6)