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
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 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 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 often nowadays the cleanup, of utmpx database entries for successful logins.
On modern BSDs the notion of utmpx records for anything other than the logged-in state of a terminal has been abolished.
Linux still retains the old notion of terminals that are in the "init", "getty", 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 additional records one simply inserts login-process into the chain:
login-prompt login-banner /etc/issue login-process 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.