This package contains tools for running and managing TUI login services on both kernel and user-space virtual terminals. It also contains pre-written service bundles for such TUI login services.
run
scripts look like
The run
scripts are interpreted by nosh
and are created from a template with the terminal name hardwired.
A run
script to provide TUI login on kernel virtual terminal /dev/ttyv4
would be something like this:
#!/bin/nosh setsid vc-get-tty ttyv4 open-controlling-tty vc-reset-tty login-banner /etc/issue.vc login
A run
script for a service to provide TUI login on user-space virtual terminal /run/dev/vc1
would be something like:
#!/bin/nosh setsid vc-get-tty vc1/tty open-controlling-tty vc-reset-tty login-banner /etc/issue.vc login
The run
scripts for these services use the chain loading tools to do what one would otherwise do with fgetty
or mingetty
.
They are even more minimal than "minimal getty
" is, and cut out much of the functionality of a full getty
that is either invariant or non-existent on virtual terminals.
Several parts of this are specialized, hardwiring things that are variable in general, but that are in fact invariant for virtual terminals.
Serial-line getty programs like mgetty
and agetty
deal in things like modem connect strings, serial line speeds, modem flow control, parity, dial-out interlocks, and suchlike.
None of those things apply to virtual terminals; and the tools are simpler for having no dealings with them.
As their names suggest, vc-get-tty
and vc-reset-tty
are specialized tools for virtual terminals; the former only knows about the terminal types for virtual terminals, and the latter only knows about the control sequences for resetting virtual terminals.
Both the terminal types and their control sequences are fixed by the user-space terminal emulator or the terminal emulator in the operating system kernel, and won't change in the way that real terminals attached to serial lines can.
The chain login-banner /etc/issue login
is a common sequence for login services.
run
scripts are recomposable and this chain is an example of that.
One can adjust the behaviour of the service to suit particular needs by altering the tool chain or particular tool options.
For examples:
Some login
programs employ an idle timeout feature, whereby they exit if login has not completed within a set period of time, such as 60 seconds.
Terminal login as a proper service, managed by a service manager, operates suboptimally if the service is continually exiting, because login
has timed out, every 60 seconds.
At the very least, it is annoying chaff in the service logs.
One way to fix this is to remove the timeout from login
's configuration file, whatever that may be, of course.
Another is to put login-prompt
into the chain:
login-prompt login-banner /etc/issue login
Having login-prompt
run first ensures that the service does not keep timing out and exiting.
The prompt that it displays is of course familiar Unix behaviour, that mimics the behaviour of serial line getty
services on variable-speed lines.
They can require that one press Return several times as the program attempts to guess the correct terminal line speed to set.
login
programs handle the creation, and nowadays also the cleanup, of utmpx
database entries for successful logins.
On BSDs the notion of utmpx
records for anything other than the logged-in state of a terminal never existed in the first place.
Linux still retains the System 5 notion of terminals that are in the "init" and "login" states, even though they no longer apply.
(The "init" state has no meaning for systems where the terminal login service isn't managed by process #1 any more; and as can be seen here there is no real "getty" state for kernel virtual terminals as most of the serial line functions of getty
don't apply.)
To maintain such obsolete records nonetheless, one simply inserts login-process
into the chain:
login-process login-prompt login-banner /etc/issue login
On Linux and BSDs, kernel virtual terminals may retain terminal state from previous logins that affects the viewability of subsequent logins.
Existing processes can also end up retaining open file descriptors for the terminal device.
To forcibly reset a virtual console, using mechanisms that are specific to kernel virtual consoles, one can employ the --hard-reset
, --text-mode
and other options to vc-reset-tty
; and to forcibly remove access to open file descriptors one can employ the --vhangup
or --revoke
options to open-controlling-tty
.
There are some differences between user-space and kernel virtual terminals that simplify such scripts yet further:
User-space virtual terminals are created afresh (a new pseudo-terminal master and slave pair) at service start, so there is no need for the --revoke
or --vhangup
option to open-controlling-tty
,
User-space virtual terminals are initialized into a sane state (both the line discipline and the terminal emulator's attributes, colours, and character repertoire) at start, so there is no need for the --hard-reset
option to vc-reset-tty
,
User-space virtual terminals do not have a graphics mode, so there is no need for the --text-mode
option to vc-reset-tty
.