<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="generator" content="Osso Notes">
<title></title></head>
<body>
<p>hi,
<br>
<br>no need to use inotify for this. merely stating the file regularly should indicate the new file with a changed inode number.
<br>
<br>i was thinking about a separate operation to reopen files (e.g. syslog-ng-ctl reopen-files) to avoid having to reload the configuration, but this idea seems simpler to implement.
<br>
<br>----- Original message -----
<br>> Patrick Hemmer <<a href="mailto:syslogng@stormcloud9.net">syslogng@stormcloud9.net</a>> writes:
<br>>
<br>> > Something which I think would be an awesome feature would be to
<br>> > monitor  open file destinations for the file being renamed or deleted,
<br>> > and then  reopen the file in such an event. The benefit of this is
<br>> > that when doing  log rotation, you don't have to SIGHUP syslog-ng to
<br>> > make it re-open  files. It would also make it so that all destination
<br>> > buffers don't have  to be flushed and reopened, just the single file
<br>> > destination.
<br>> >
<br>> > The only downside is portability as not all OSs support the same way
<br>> > of  doing this. On linux this can be easily done through inotify, and
<br>> > it  looks like the BSD equivalent is kqueue (though I have pretty much
<br>> > no  BSD experience). For platforms which there isn't a good method, we
<br>> > could  instead fall back to a simple polling.
<br>>
<br>> I've been thinking about something similar recently, though, my desire
<br>> started from a completely different angle: I'd love to have wildcard
<br>> file sources, and possibly other stuff (like allow some macros in file
<br>> sources, though that opens up a nasty can of worms).
<br>>
<br>> That needs some kind of monitoring too, and if sources have it, we can
<br>> reuse the same thing for similar tasks on the destination side too.
<br>>
<br>> I planned to write an RFC (with a little bit more detail about how I
<br>> imagine it would work, and what good things it'd bring us) about this in
<br>> the next day or two, but the rabbit's out the hat now. On the flip side,
<br>> I originally didn't think about how file monitoring could be used for
<br>> destinations, but your mail enlightened me - thank you!
<br>>
<br>> --
<br>> |8]
<br>>
<br>> ______________________________________________________________________________
<br>> Member info: <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a>
<br>> Documentation:
<br>> <a href="http://www.balabit.com/support/documentation/?product=syslog-ng">http://www.balabit.com/support/documentation/?product=syslog-ng</a> FAQ:
<br>> <a href="http://www.balabit.com/wiki/syslog-ng-faq">http://www.balabit.com/wiki/syslog-ng-faq</a>
<br>>
<br><br></p>
</body>
</html>