As you have spotted, the
login program can be, and usually is, configured to time out if no input is received for a certain number of seconds. There are various motivations for this behaviour, ranging from wanting to keep unused dial-up lines clear to the world wanting you to clean your screen. There are, equally, reasons for not wanting it, as you have here. Hanging up to clear the line is fairly meaningless if there's no modem, for one thing.
login programs vary in this regard. The
login from (say) Debian's login package respects a
/etc/login.defs configuration file. I have
LOGIN_TIMEOUT set to 0 in mine. But other
login programs have this unconfigurable and hardwired. There is more than just the one
login program in the world. ☺
login program in FreeBSD is — alas! — one such. So too, is the
login program that is built in to Busybox. The former has a hardwired timeout of 300 seconds; the latter, a mere 60 seconds.
The Busybox code is a compile-time constant. You'll have to actually modify the source to the program and re-build it in order to disable this behaviour. Per commentary in the code of the FreeBSD
login program that explains why it is a run-time variable not a compile-time constant, the FreeBSD authors expect you to vary this by patching the
/usr/bin/login binary itself.
There are a few mitigating strategies. One is — alas! — to keep
getty in the loop. FreeBSD's
login is invoked by FreeBSD's
getty, which has a
to capability in
/etc/gettydefs that is normally set to zero. Busybox's
getty similarly has a
-t option. Both mean that an idle, not logged in, serial terminal sits forever at the
login: prompt displayed by
getty, and the timeout in
login is not begun.
I don't use
getty on virtual terminals, myself. So for FreeBSD I have a very simple
login-prompt program that simply waits for the user to press return. And on Linux I turn off the timeout with
login.defs as mentioned.
For real terminals on serial lines, however, I still use