When I run ./tools/cjdnslog -f InterfaceController.c it shows logs from that file. Cool. When I interrupt cjdnslog and restart it, it... sometimes shows logs from that file. Eventually, it never shows logs from that file at all, even when they are being generated, and the only way to start it working again is to kill cjdroute and restart it.
Running ./cjdnslog by itself without specifying -f continues to work, and continues to display logs from InterfaceController.c. But adding "-f InterfaceController.c" just gives no more output at all, indefinitely.
This makes it difficult to respond to specific events, since your program just hangs waiting for logs that never come, instead of detecting that a peer has gone unresponsive. And parsing all logs everywhere at 'DEBUG' level and higher isn't really an ideal solution.
This seems a problem with the logging subscription interface in general, because other programs that behave similarly also have their logging fail. I did a tcpdump of the admin port, and as far as I could tell, it just sent AdminLog_subscribe, received no data, then sent AdminLog_unsubscribe when I interrupted it.
When I run ./tools/cjdnslog -f InterfaceController.c it shows logs from that file. Cool. When I interrupt cjdnslog and restart it, it... sometimes shows logs from that file. Eventually, it never shows logs from that file at all, even when they are being generated, and the only way to start it working again is to kill cjdroute and restart it.
Running ./cjdnslog by itself without specifying -f continues to work, and continues to display logs from InterfaceController.c. But adding "-f InterfaceController.c" just gives no more output at all, indefinitely.
This makes it difficult to respond to specific events, since your program just hangs waiting for logs that never come, instead of detecting that a peer has gone unresponsive. And parsing all logs everywhere at 'DEBUG' level and higher isn't really an ideal solution.
This seems a problem with the logging subscription interface in general, because other programs that behave similarly also have their logging fail. I did a tcpdump of the admin port, and as far as I could tell, it just sent AdminLog_subscribe, received no data, then sent AdminLog_unsubscribe when I interrupted it.