0

we have quite a large system that relies on FTP messaging. /var/log/pureftpd.log is under surveillance to respond to specific actions.

Currently, I noticed an interesting problem where pure-ftpd is logging a new events to the old logfile for example (pureftpd.log.1).

This happens in situations when FTP connection is open for a long time. When logrotate rotates log file by renaming old log. It seems that currently active FTP connections are still linked to the old file and all events are written there. This will get fixed after the FTP client reconnects.

This behaviour makes pureftpd surveilance fail to register some events.

How it can be fixed using logrotate.d or another means to ensure that all new events are always written into proper logfile without reconnecting ftp clients?

pure-ftpd is running on Default settings and logrotate configuration is as follow:

/var/log/pureftpd.log {
    weekly
    notifempty
    missingok
}

Thank you for any recommendation :)

Martin Tomko
  • 155
  • 1
  • 1
  • 13

1 Answers1

1

This is common behavior for processes that open file descriptors to write; logrotate does not deal with these open handles, as such they will 'follow' along to the newly rotated file. Hence the behavior you're seeing.

I assume that you have to either reload or restart the pure-ftpd daemon itself after rotating the file, e.g. assuming systemd:

postrotate
    systemctl reload pure-ftpd > /dev/null
endscript

Whether or not this will kill all your connections I don't know. But that is the source of the behavior you're seeing.

parttimeturtle
  • 1,125
  • 7
  • 22