[RndTbl] Screen in production

Robert Keizer robert at keizer.ca
Wed Oct 10 09:50:11 CDT 2012


I've been running screen for a while now - I use it day to day 
operations just fine, and occasionally when I'm in a pinch I use it for 
a serial terminal.

The way you scroll up in screen ( or atleast the way that I've found 
that seems to be standard ) is to use ctrl + a then [. This puts you 
into "copy mode", and there are some nice features in there. My issue 
was thus:

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. 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.

Enter problem: Disconnecting from the screen ( ctrl+a ) d, leaving it in 
copy mode. Turns out that screen _blocks_stdout_ while it is in copy 
mode. Depending on what kind of program you're running in screen this 
could be bad.

In my case it was pretty annoying because _monitoring_didn't_catch_it_ 
as the program was still responding to tcp connections. It was block 
writing to stdout. Because the blocking stdout command was in its own 
function and I am using an async javascript program without waiting for 
a callback, other parts of the system still worked.

Thought I'd share. Make sure you hit esc+esc on production screen 
stuff.. it blocks stdout!


More information about the Roundtable mailing list