16

Default behaviour by rsyslog is to append traces to an existing log file.

Now, I've seen (CentOs, Scientific Linux) that when rsyslog is already running, you delete the log file (e.g. the one dedicated to log traces from your application), you then run your application, rsyslog will not create a log file and no trace will be recorded.

Is there a config option somehow that can tell rsyslog to create a log file if not there before appending traces to it?

Note: doing a service rsyslog restart will force creation of an empty log file.

rsyslog.conf (nothing added to it)

# rsyslog v5 configuration file

# For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html
# If you experience problems, see http://www.rsyslog.com/doc/troubleshoot.html

#### MODULES ####

$ModLoad imuxsock # provides support for local system logging (e.g. via logger command)
$ModLoad imklog   # provides kernel logging support (previously done by rklogd)
#$ModLoad immark  # provides --MARK-- message capability

$SystemLogRateLimitInterval 1
$SystemLogRateLimitBurst 50000

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

# Provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514


#### GLOBAL DIRECTIVES ####

# Use default timestamp format
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# File syncing capability is disabled by default. This feature is usually not required,
# not useful and an extreme performance hit
#$ActionFileEnableSync on

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


#### RULES ####

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none;local1.none    /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog


# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 *

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

# ### begin forwarding rule ###
# The statement between the begin ... end define a SINGLE forwarding
# rule. They belong together, do NOT split them. If you create multiple
# forwarding rules, duplicate the whole block!
# Remote Logging (we use TCP for reliable delivery)
#
# An on-disk queue is created for this action. If the remote host is
# down, messages are spooled to disk and sent when it is up again.
#$WorkDirectory /var/lib/rsyslog # where to place spool files
#$ActionQueueFileName fwdRule1 # unique name prefix for spool files
#$ActionQueueMaxDiskSpace 1g   # 1gb space limit (use as much as possible)
#$ActionQueueSaveOnShutdown on # save messages to disk on shutdown
#$ActionQueueType LinkedList   # run asynchronously
#$ActionResumeRetryCount -1    # infinite retries if host is down
# remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional
#*.* @@remote-host:514
# ### end of the forwarding rule ###
1
  • Can you share your .conf file?
    – slm
    Sep 26, 2013 at 19:09

2 Answers 2

14

From rsyslog's POV, the deleted log file still exists. This is because rsyslog isn't writing to the filename, it is writing to the file handle it has open for the log file.

Unix systems don't actually delete a file until there are no processes with open handles to the file. This means that the disk space used by the deleted file is not freed until any and all open file-handles are closed. It also means that any processes with open file handles to the deleted file can continue reading from and/or writing to the file.

Sending a HUP signal (e.g. via pkill -HUP rsyslog or /etc/init.d/rsyslog rotate) to rsyslog tells it to close all its opened files, reload its config file, and re-open all log files for write (creating them if necessary).

Restarting rsyslogd also works.

Note that this is a feature, not a bug, with some useful implications - e.g. it's why rsyslog keeps writing to the same log file even after it has been rotated (i.e. renamed/mv-ed) until rsyslog receives a HUP signal. This means that log-processing scripts & utilities don't have to be scrupulously careful about timing - they can just rotate all the logs, send rsyslog a HUP, and everything continues working, with no loss of log data.

BTW, the only way for this not to happen with rsyslog would be it if closed and re-opened every log file on every write (or at least called sync()). Performance would be abysmal.

5
  • Do you know off hand if a kill -HUP to rsyslog will trigger it to start writing to a new file?
    – slm
    Sep 26, 2013 at 22:50
  • you mean, if rsyslog.conf has changed and there's a new log file defined? yes, it definitely will create and start writing to the new file on receiving a HUP...that's part of the point of it re-loading the config.
    – cas
    Sep 26, 2013 at 22:57
  • OK, that's what I suggested in my 3rd method, thanks!
    – slm
    Sep 26, 2013 at 23:00
  • the problem is rsyslog is running, you delete an application log file (without restarting rsyslog) and then no more trace will be logged as rsyslog will not create the log file if not there whilst it's running...
    – fduff
    Oct 1, 2013 at 8:19
  • 1
    as i said, from rsyslog's POV, that file handle still exists. it will not close and re-open/re-create the log files until you tell it to by restarting it or with a HUP signal. rsyslog does what you tell it to do, no more. more importantly, the problem is not in what rsyslog does, but in your understanding of rsyslog's behaviour and why it behaves like that.
    – cas
    Oct 1, 2013 at 13:19
3

$FileCreateMode

Does this option not do what you want, $FileCreateMode?

excerpt

$FileCreateMode 0600

This sample lets rsyslog create files with read and write access only for the 
users it runs under.

The following sample is deemed to be a complete rsyslog.conf:

$umask 0000 # make sure nothing interferes with the following definitions
*.* /var/log/file-with-0644-default
$FileCreateMode 0600
*.* /var/log/file-with-0600
$FileCreateMode 0644

*.* /var/log/file-with-0644

File Output Module

According the the rsyslog documentation, the File argument of the File Output Module could be used to do this.

excerpt omfile module

File

If the file already exists, new data is appended to it. Existing data is not truncated. If the file does not already exist, it is created. Files are kept open as long as rsyslogd is active. This conflicts with external log file rotation. In order to close a file after rotation, send rsyslogd a HUP signal after the file has been rotated away.

Send syslog a HUP signal

I think ultimately you need to "trigger" rsyslog to do this. I don't think it will what you want automatically. So you could give it a HUP signal to trigger the re-creation of the log file after it's deleted.

$ sudo pkill -HUP rsyslog

Doing so created the following messages in my /var/log/messages log file:

Sep 26 15:16:17 grinchy rsyslogd: [origin software="rsyslogd" swVersion="4.6.3" x-pid="1245" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
Sep 26 15:16:44 grinchy rsyslogd: [origin software="rsyslogd" swVersion="4.6.3" x-pid="1245" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
4
  • No, I've used it to set file permissions and that works fine. The problem is that if the log file has been removed, syslog will not attempt to create it before logging msg.
    – fduff
    Sep 26, 2013 at 18:31
  • It's been deleted, and the server hasn't been restarted?
    – slm
    Sep 26, 2013 at 18:33
  • exactly. I'm doing some tests and I came across this particularity...
    – fduff
    Sep 26, 2013 at 18:34
  • @fduff - see my updates, try the 3rd one!
    – slm
    Sep 26, 2013 at 19:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .