Hi! Syslog-ng reopens destination files, if I send a SIGHUP to the process, which is a common way of handling logrotates in Linux. If I don't write in to a file (idle), syslog-ng will close the file according to time_reap() value. If the file was deleted from the directory, will it create the file next time it logs to the deleted destination file? I've found, that it doesn't, can I config it somehow? (My log files are read by different users, and sometimes they delete it, so it should be recreated again.) Is it a soultion, if I send a SIGHUP to syslog-ng every minute? I was looking for a solution in the archive, but I haven't found a clear answer. Thanks, Balazs Szeti
Hello,
Hi!
Syslog-ng reopens destination files, if I send a SIGHUP to the process, which is a common way of handling logrotates in Linux. If I don't write in to a file (idle), syslog-ng will close the file according to time_reap() value. If the file was deleted from the directory, will it create the file next time it logs to the deleted destination file?
syslog-ng creates the non-existing destination files when it has the permission to write to the target directory. However if the file was hold open by syslog-ng and something deleted the file, then the fd would be used by syslog-ng for writing still, while the filesystem wouldn't show the file anymore. You can check with lsof whether this is happening to you or not.
I've found, that it doesn't, can I config it somehow? (My log
As I mentioned above your assumption is incorrect.
files are read by different users, and sometimes they delete it, so it should be recreated again.) Is it a soultion, if I send a SIGHUP to syslog-ng every minute?
No. This could be a very bad practice - in theory during the signal processing/ reloading you could lose messages, or at least this was the case before. Maybe this has changed recently, I'm not sure about this. Regards, Sandor -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
participants (2)
-
Geller, Sandor (IT)
-
Szeti, Balazs