0

I am very new to rsyslog and I am going through the documentation as well as seeing examples of what other people have done with their configuration and a question came to mind when the topic of log rotation was brought up. Currently in my server, there is configuration to filter certain messages to a non-default log file and that log file has a logrotate configuration file, but a saw that there is a logrotate configuration file for syslog that executes kill -HUP on rsyslog's process ID.

I understand the need to restart an application that is holding a file descriptor after the file has been renamed, modified, etc, but how does this affect a syslog server receiving UDP messages? If rsyslog needs to restart, there is a window of time where the UDP ports are no longer bound to a process so any messages being sent remotely to the server are then lost. Is the window of time so short this is not something I should worry about or is there a different approach to tackle such a possibility? (Using TCP is not a possibility for internal/out-of-my-control reasons.)

Currently running RHEL 6.10 with rsyslog 8.2004.

4
  • 2
    Sighup closes open files, it does not fully restart rsyslogd, so the ports should remain open. Note, however, that there is no guarantee of delivery for UDP, so you might lose a packet at any time.
    – meuh
    May 2, 2020 at 17:45
  • 1
    I'm running 8.24 . Checking the source was a bit too much to follow, so I experimented using strace: I don't see any socket reopened after the HUP, while there are UDP sockets kept open which don't change. The best would of course be to follow sources.
    – A.B
    May 2, 2020 at 18:07
  • @meuh by the nature of UDP, that is always a possibility, but during an audit no one would be able to blame it on server availability, which is one of the reasons for my question.
    – AnthonyBB
    May 2, 2020 at 18:14
  • 1
    Note that rsyslogd is multi-threaded, so the threads writing to files should not affect the threads listening on ports.
    – meuh
    May 2, 2020 at 18:20

1 Answer 1

0

kill -HUP sends the HANGUP signal to the process. This does not necessarily kill the process. Checking the man page states that

Also, in v3 a full restart will be done in order to read changed configuration files. Note that this means a full rsyslogd restart is done. This has, among others, the consequence that TCP and other connections are torn down.

So that means your side-note of TCP won't help either. Since UDP is connectionless, you might lose some anyway. But if a packet comes in during that tiny window of time, you may get a ICMP response saying that port is not listening, depending on how the server / firewalls are configured. How the sending app will treat that ICMP response is something you will also need to consider.

2
  • 2
    That man page seems to be very out of date. See the source
    – meuh
    May 2, 2020 at 18:01
  • Oh good; that's kind of what I expected when I was writing the intro sentences - HUP doesn't necessarily mean kill... May 2, 2020 at 20:35

You must log in to answer this question.

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