The value is not explicitly set, so it will be whatever the default is
for that version (3.18.6-4).  Here's the full rsyslog.conf.  There are
no files in /etc/rsyslog.d, so the include statement isn't pulling in
any other changes.



#  /etc/rsyslog.conf    Configuration file for rsyslog v3.
#
#                       For more information see 
#
/usr/share/doc/rsyslog-doc/html/rsyslog_conf.html


#################
#### MODULES ####
#################

$ModLoad imuxsock # provides support for local system logging
$ModLoad imklog   # provides kernel logging support (previously done by
rklogd) 
#$ModLoad immark  # provides --MARK-- message capability

# provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

# provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514


###########################
#### GLOBAL DIRECTIVES ####
###########################

#
# Use traditional timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

#
# Set the default permissions for all log files.
#
$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755

#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf


###############
#### RULES ####
###############

#
# First some standard log files.  Log by facility.
#
auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
#cron.*                         /var/log/cron.log
daemon.*                        -/var/log/daemon.log
kern.*                          -/var/log/kern.log
lpr.*                           -/var/log/lpr.log
mail.*                          -/var/log/mail.log
user.*                          -/var/log/user.log

#
# Logging for the mail system.  Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info                       -/var/log/mail.info
mail.warn                       -/var/log/mail.warn
mail.err                        /var/log/mail.err

#
# Logging for INN news system.
#
news.crit                       /var/log/news/news.crit
news.err                        /var/log/news/news.err
news.notice                     -/var/log/news/news.notice

#
# Some "catch-all" log files.
#
*.=debug;\
        auth,authpriv.none;\
        news.none;mail.none     -/var/log/debug
*.=info;*.=notice;*.=warn;\
        auth,authpriv.none;\
        cron,daemon.none;\
        mail,news.none          -/var/log/messages

#
# Emergencies are sent to everybody logged in.
#
*.emerg                         *

#
# I like to have messages displayed on the console, but only on a
virtual
# console I usually leave idle.
#
#daemon,mail.*;\
#       news.=crit;news.=err;news.=notice;\
#       *.=debug;*.=info;\
#       *.=notice;*.=warn       /dev/tty8

# The named pipe /dev/xconsole is for the `xconsole' utility.  To use
it,
# you must invoke `xconsole' with the `-file' option:
# 
#    $ xconsole -file /dev/xconsole [...]
#
# NOTE: adjust the list below, or you'll go crazy if you have a
reasonably
#      busy site..
#
daemon.*;mail.*;\
        news.err;\
        *.=debug;*.=info;\
        *.=notice;*.=warn       |/dev/xconsole



-----Original Message-----
From: Rainer Gerhards [mailto:[email protected]] 
Sent: Thursday, October 22, 2009 1:30 AM
To: Michael Biebl; [email protected]
Cc: Groose, Brian
Subject: RE: Bug#550391: /dev/log sometimes disappears upon "rsyslog
reload"

Is $HUPisRestart set to "on"?

Rainer 

> -----Original Message-----
> From: Michael Biebl [mailto:[email protected]] 
> Sent: Thursday, October 22, 2009 12:19 AM
> To: [email protected]; Rainer Gerhards
> Cc: Brian Groose
> Subject: Re: Bug#550391: /dev/log sometimes disappears upon 
> "rsyslog reload"
> 
> Brian Groose wrote:
> > Package: rsyslog
> > Version: 3.18.6-4
> > Severity: important
> > 
> > Sometimes we see /dev/log disappear for a while when 
> "rsyslog reload" is invoked, typically by logrotate.
> > I've narrowed down steps to reproduce this bug:
> > 
> > 1. Start with a standard lenny install with default syslog settings
> > 2. Modify /etc/rsyslog.conf and uncomment out the following 
> lines to enable TCP logging:
> >    #$ModLoad imtcp
> >    #$InputTCPServerRun 514
> > 3. Restart or reload rsyslog so the TCP setting is in effect.
> > 4. Put some logging load on rsyslog. This works nicely:
> >   while [ 1 ] ; do logger "Test" ; done
> > 5. Call "/etc/init.d/rsyslog reload" in a loop with a short 
> sleep in between.  Watch
> >    for /dev/log not appearing very shortly after the reload.
> > 
> > 
> > In my testing, I reloaded 1000 times with a 0.1s sleep in 
> between, and 10 of the
> > reloads resulted in /dev/log going away.  /dev/log came 
> back after exactly one
> > minute in every one of those 10 times (I was no longer 
> calling reload while
> > waiting for /dev/log to reappear), but during that one 
> minute nothing can write
> > log messages because /dev/log is gone. 
> > 
> > Rsyslog appeared to still be listening on port 514, though 
> since this test does
> > not used TCP logging, I could not verify if logging to port 
> 514 actually worked.
> > 
> > I did not have any issues if TCP logging was disabled or if 
> there was nothing being
> > actively logged.
> 
> Hi Rainer,
> 
> could you take a look at that.
> Shouldn't a simple reload keep /dev/log available?
> Or is rsyslog doing a full restart on "reload" due to 
> listening on tcp port 514?
> 
> Cheers,
> Michael
> 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 
> 
The information contained in this email message and its attachments
is intended
only for the private and confidential use of the recipient(s) named
above, unless the sender expressly agrees otherwise. Transmission
of email over the Internet
 is not a secure communications medium. If you are requesting or
have requested
the transmittal of personal data, as defined in applicable privacy
laws by means
 of email or in an attachment to email you must select a more
secure alternate means of transmittal that supports your
obligations to protect such personal data. If the reader of this
message is not the intended recipient and/or you have received this
email in error, you must take no action based on the information in
this email and you are hereby notified that any dissemination,
misuse, copying, or disclosure of this communication is strictly
prohibited. If you have received
this communication in error, please notify us immediately by email
and delete the original message.



--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

Reply via email to