[RndTbl] Screen in production

[Adam Thompson]

IIRC, stderr doesn't buffer, stdout does.  Both must block eventually once they hit the maximum buffer size the kernel and/or libc impose.
Buffering != blocking.
-Adam

Robert Keizer <robert at keizer.ca> wrote:

>On 12-10-10 10:33 AM, Gilbert E. Detillieux wrote:
>> On 2012-10-10 09:50, Robert Keizer wrote:
>>> I have a production service that prints some debug to stdout. I could
>>> make it print to stderr, but it really doesn't matter in this case.
>>
>> Are you sure it doesn't matter?  Read on...
>>
>>> I want to have some hope of if something goes wrong figuring out what 
>>> did.
>>> Log files aren't really an option so I ran it in screen. Yes yes I could
>>> have made it network log to somewhere else, but again, not really an
>>> viable option in this case. Works great as the program dies and the
>>> output stops, leaving the last debug messages in the buffer of screen.
>>
>> One of the classic C/UNIX lessons about stdout vs stderr is that the C 
>> library buffers stdout by default but not stderr, exactly for the 
>> reason that you want error messages to be flushed out right away, 
>> leaving nothing in the buffer.  This is particularly important if the 
>> program dies in a way that prevents the usual exit processing, such as 
>> flushing buffers and closing file I/O.
>>
>> So, issues with "screen" aside, you probably should either send your 
>> debug output to stderr, or set your stdout to unbuffered mode while 
>> debugging (or both).
>>
>
>Interesting!
>
>Thought I'd test out stdout vs stderr just to see if this was in fact 
>the case. It's not - stderr and stdout have the same effect in this case.
>
>Below is a script the listens for incoming data on a given port ( 
>example is 1337 ). When data is received it writes to either stdout or 
>stderr and then sends data on to another port ( in this case 1338 ). 
>This script also fills up the screen buffer by a simple loop ( tested 
>filling with both stderr and stdout ).
>
>Using telnet to feed the script data, and nc ( nc -lk 1338 ) to listen 
>on port 1338 for the output, one can test to confirm.
>
>
>net = require "net"
>server = net.createServer ( c ) ->
>         c.setEncoding "utf8"
>         c.on "data", ( data ) ->
>                 _c = net.createConnection 1338, ( ) ->
>                         process.stderr.write "Data: " + data + "\n"
>                         _c.write data
>                 _c.end( )
>
>server.listen 1337, "127.0.0.1"
>loops = ( ) ->
>         process.stderr.write "Loopies: " + Date( ) + "\n"
>         setTimeout loops, 100
>loops( )
>
>Screenshot is attached - it shows this script in the top left running in 
>screen, with copy mode enabled. Right of it is the telnet session 
>feeding it, and on the bottom left is the nc or "output". Note that the 
>last two inputs did not make it to the output. Ergo, unless I'm totally 
>an idiot in my implementation: This is blocking on stderr as well.
>
>Thoughts? Because now I'm officially annoyed that this blocks on stderr 
>as well!
>
>Rob
>
>
>_______________________________________________
>Roundtable mailing list
>Roundtable at muug.mb.ca
>http://www.muug.mb.ca/mailman/listinfo/roundtable