Way back in the dark ages of Linux, I had a bunch of machines which
didn't run X. They were strictly text mode, and sat there doing
whatever I needed them to do: routing, DNS, dialups, mail, RADIUS auth,
you name it. There were plenty of daemons working for me, and most of
them had things to say via the syslog.
To keep an eye on things, I would just watch the syslog by tailing files
like /var/log/messages. That was all well and good, but it meant having
to be logged in. If I was logged in, then there was a console open,
just a single ^C away from giving a shell to anyone who came by. This
was before the days of "cheesing", "Biebering", or "jelloing" unlocked
terminals, but I still didn't like it.
One day I noticed that you could create a new text console on a Linux
box just by shoving some data at the right /dev entry. Just "echo"
something to /dev/tty12, then ALT-F12 and you'd be able to see it.
Prior to that, ALT-F12 would do nothing since it didn't exist yet.
From that discovery it was just a hop, skip and a jump to having syslogd
write a second copy of everything to /dev/tty12. Then I could log out,
flip to that virtual console, and watch things that way. Any time I
wondered what was happening, a quick tap on the keyboard to turn the
screen back on would let me see without logging in.
That's how it went for a while, but then one day basically everything
on that machine stopped responding. It's been a long time so I forget
exactly transpired in the middle, but eventually it came down to one
thing: my keyboard's scroll lock light was glowing at me when I was on
Yep, that key that basically has been a part of the PC keyboard layout
forever and never really did anything finally had a purpose, and on
Linux, it served to stop writes to a text console. This was all well
and good in theory, but since syslogd was doing blocking writes to it,
that also meant syslogd would get jammed. These days, that wouldn't be
a problem, but back then,
/dev/log was connection-based.
When syslogd got stuck, it stopped reading /dev/log, and eventually that
became a trap, too. Anything trying to talk to it also blocked. Given
that sendmail and a bunch of other things all called syslog(), this made
for a pretty messy situation.
Someone had pressed the scroll lock key on the keyboard while that tty
was active. Maybe it was me, or maybe it was something fooling around,
or maybe it was just the cleaning crew "doing me a favor". It doesn't
What inspired me to write about this today is stumbling over something
similar not too long ago. I have a couple of programs which run in
screen, mostly out of sheer laziness on my part. This is fine until you
accidentally hit ^S while attached to it. ^S is XOFF, or for those of
you who are lucky enough to not have to know this... is part of
software flow control.
Yep, ^S, 0x13, decimal 19, DC3, whatever you want to call it, is usually
interpreted as XOFF. It'll sit there and block writes until someone
sends it ^Q, 0x11, decimal 17, DC1, which is XON.
Anyway, let's say you're in screen, which by default uses ^A as a
command key. ^A N goes to the next screen, ^A D detaches, and so on.
If you're on a vaguely QWERTY-ish layout, you'll notice that A and S
are right next to each other.
It's not much of a stretch to imagine accidentally hitting that S
instead of A. At that point, all of the writes block until you either
unwedge it with ^Q or bail out of screen. If you didn't know what was
going on behind the scenes, it might just seem like "one of those things
that happens sometimes".
If you've ever wondered why some folks hit ^Q any time things seem to
have frozen in their terminal, this might be why.