remote_syslog 1.6.14 keeps old logfiles open

[rolandkool]

Consider the following directory stucture:
/path/to/logs/myapp
/path/to/logs/myapp-2013-09-10
/path/to/logs/myapp-2013-09-09

If we watch /path/to/logs/myapp/*.log and the directory is moved to /path/to/logs/myapp-2013-09-11 and a new directory is created called /path/to/logs/myapp remote_syslog will keep the files in /path/to/logs/myapp-2013-09-11 open and start watching the logs in the newly created /path/to/logs/myapp

Eventually the process will run out of available files and stop working.

How can we get around this problem, besides restarting the service daily?

[coryvirok]

+1

[troy]

+1 from me too, and I wrote a lot of it ;-) Unfortunately, it's an artifact of the async file I/O library that remote_syslog relies on. I don't have a direct solution to this problem, but do have some relevant and hopefully promising news: this and other problems led us to rewrite remote_syslog in Go.

We didn't do so for the language difference. Go was attractive was because we're not dependent on a VM and not as dependent on library implementation decisions (or as in this case, bugs). Supporting VM-dependent daemons in thousands of environments is less fun than it sounds.

So, stay tuned for a rewrite which should fix this issue, or at least put us in a position where it's practical to do so. A firm release date would be as meaningless as any other date in software, but I can say we've actually run feature-complete builds :)

[blaind]

+1 * multiple from here too :)

Havent tried, and had only a quick look at the code. Would something like this work?

• Watch_file would always create an array of watched files
• RemoteSyslog::Globwatch finds a new file, which results to RemoteSyslog::watch_file being called
• When watch_file is called, it'd check from the array whether existing watch for given file is already running. If yes, it would stop the relevant watcher (EventMachineReader or FileTailReader).

Edit: works if both watchers can be stopped, is this the problem with I/O libraries used?

[troy]

I don't know what concurrency EventMachine::FileGlobWatch provides for callbacks to its notification method (in this case, watch_file), but if you implement that, it may need to protect the array from concurrent modification.