views:

49

answers:

1

I am developing under Linux with pretty tight constraints on disk usage. I'd like to be able to point logging to a fixed-size file. For example, if my application outputs all logs to stdout:

~/bin/myApp > /dev/debug1

and then, to see the last amount of output:

cat /dev/debug1

would write out however many bytes debug1 was setup to save (if at least that many had been written there).

This post suggests using expect or its library, but I was wondering if anyone has seen a "pseudo-tty" device driver-type implementation as I would prefer to not bind any more libraries to my executable.

I realize there are other mechanisms like logrotate, but I'd prefer to have a non-cron solution.

Pointers, suggestions, questions welcome!

+1  A: 

Perhaps you could achieve what you want using mkfifo and something that reads the pipe with a suitable buffer. I haven't tried, but less --buffers=XXXXXX might work for this.

Bruno
Nice suggestion! Unfortunately, it seems that redirection to a named pipe causes what I'm trying to avoid: the process starts in non-interactive mode, and buffers output (I think the default is 4K worth).
Peter K.
When you say "non-interactive mode", do you mean that the normal output is also redirected to that named pipe or that somehow the application detects that its stdout is redirected and thus behaves differently (which I didn't know was possible)? (It could be possible to detect that there's no console (input) by closing stdin.)If the problem is that the logs are mixed with your normal output on stdout, you should probably change the application to send the logs on stderr instead (and use `2>` for the redirection), if you can.
Bruno
If you can't change the logs to be on stderr instead, you might be able to keep the entire screen output using the `script` command (http://linux.die.net/man/1/script) or `screen` and perhaps configure the buffers to suit your needs.Alternatively, if your logs have a certain text pattern, you might be able to split them and the regular output using a combination of named piped, `tee` (to send to both the console and the named pipe) and `grep` / `grep -v` to filter the output.
Bruno
Thanks again for the great feedback! Past of my problem is that I don't necessarily have control over the apps output to stdout. I'll see if there's anything I can do about it. Again: thanks for the useful ideas.
Peter K.
PS: The mkfifo idea got stuck because the app will block until someone is reading on the other end...
Peter K.