Bug 436866

Summary:	RFE: RHEL5.3 - Option for sysklogd to not create log files if they do not already exist in /var/log/
Product:	Red Hat Enterprise Linux 5	Reporter:	David Mair <dmair>
Component:	sysklogd	Assignee:	Peter Vrabec <pvrabec>
Status:	CLOSED WONTFIX	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.3	CC:	duck, jrieden, jwest, riek, sgrubb, tao
Target Milestone:	rc	Keywords:	FutureFeature, Reopened, Triaged
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-01-17 17:19:59 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:
Bug Depends On:
Bug Blocks:	554476, 729785

Description David Mair 2008-03-10 20:25:29 UTC

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
upstream behaviour.

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
Minor 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)

sysklogd
<==

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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 6 Peter Vrabec 2008-05-12 12:26:03 UTC

I would recommend to start sysklogd after the SAN is up

Comment 8 Peter Vrabec 2008-05-16 14:50:20 UTC

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?

Comment 10 RHEL Program Management 2008-07-21 23:05:11 UTC

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

Comment 14 RHEL Program Management 2009-03-26 16:54:02 UTC

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

Comment 16 Daniel Riek 2009-10-07 01:59:58 UTC

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.

Comment 19 Peter Vrabec 2009-11-18 12:58:02 UTC

Created attachment 370072 [details]
draft

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.
example:
syslog.err                /dev/console

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)