Quote:
Originally Posted by
matrixmadhan
Yes, thats right. But in the most of the cases the systems are loosely coupled by design such that each of the unit performs their job so seldom you could control the functionality or add functionality to process that is creating the log messages.
I agree it is uncommon but the OP stated he didn't want to read the output file for some reason.
If there are valid reasons not to read the file and then not to use the usual and sensible ways suggested elsewhere ("tail -f" or custom equivalent), then Solaris allows to still fulfill the requirement in at least one of these ways. The last two suggestions aren't intrusive to the process creating the log messages.
- patching the code that writes the data (only if source code is available).
- interpose a library that intercept the pattern write
- use a dtrace script to do the same
Of course, my suggestions probably do not make that much sense in this particular case as there are probably no valid reason not to read data appended to the output file. I would however support them should a very fast response time (<1s) is expected.
Eventing is faster and less demanding than polling.
09-07-2008