login-process — chain-load utility for recording obsolete login accounting entries
login-process
[--id id
] {next-prog
}
login-process is a chain-loading utility that is used for compatibility with the obsolete /etc/inittab
mechanism where login(1) is not properly dealing with login accounting (as modern versions do and should).
It chain loads to next-prog
with the execvp(3) function.
It determins a terminal character device filename.
This can be either a virtual or a real terminal.
It primarily expects to inherit this as the value of the TTY
environment variable, which it expects to have been set up by a program such as vc-get-tty(1) or pty-get-tty(1).
If the environment variable is absent, it calls the ttyname(3) library function.
next-prog
may contain its own command line options, which login-process will ignore.
login-process makes no alteration to process state.
BSD operating systems have never had /etc/inittab
and this command simply does nothing at all.
There are simply no or empty "active terminal login" table entries for terminals where no-one is currently logged in; and the active terminal login table is indexed by terminal device (base)name, not by some "id" out of /etc/inittab
.
This utility need not be used at all on such operating systems.
In the obsolete /etc/inittab
system the active terminal login table is indexed by the "id" field from /etc/inittab
or by its process ID field, depending from who is doing the lookup.
The system manager process only knows the "id" and doesn't know the terminal device name, which isn't a field in /etc/inittab
.
The various "getty" and "login" programs know their own process IDs, but don't know the "id" field of the /etc/inittab
record that spawned them.
The system manager process is expected to have created a utmpx(3) active terminal login table entry of type INIT_PROCESS
with the process ID of the forked process and the "id" field from the /etc/inittab
record; and the "getty" process (of whatever stripe) is expected to use its process ID to find that record and change it to LOGIN_PROCESS
.
All this so that the login(1) command can use its process ID to find that record and change it to USER_PROCESS
.
login-process emulates this.
There simply is no /etc/inittab
on systems managed by system-manager(1), systemd, upstart, or other system managers.
So it determines a fictitious "id" field from the value of the terminal device name, unless forcibly overridden with the --id command option.
There is no fixed convention for this, as there is no enforced convention between IDs and terminal device names in the old /etc/inittab
system.
It discards any /dev/
or /run/dev/
prefix.
In an ideal world, this would be the sole mechanism and the ID would be what results.
However, this is not what other softwares, including GUI terminal emulators, do.
If the remaining terminal line name begins with "vc
" and ends with "/tty
", as is conventionally the case with user-space virtual terminals, the ID is the string less the "/tty
" suffix.
On Linux: if it can discard any further tty
, pty
, tts
, or pts
prefixes, the remainder becomes the ID; otherwise, it discards any further non-digit characters up until the first digit character.
So:
"/run/dev/vc1/tty
" becomes "vc1
".
"/dev/pts/5
" becomes "/5
" on Linux and "pts/5
" otherwise.
"/dev/tty5
" becomes "5
" on Linux and "tty5
" otherwise.
"/dev/ttyv5
" becomes "v5
" on Linux and "ttyv5
" otherwise.
Ironically, this song and dance is exactly what GUI terminal emulator programs have already had to do anyway, inventing a nonce "id" and adding new USER_PROCESS
records with no existing record to overwrite.
Real/virtual terminal login can just take the same approach, and entirely do away with the INIT_PROCESS
and LOGIN_PROCESS
states like both FreeBSD/DragonFly BSD and GUI terminal emulator programs do.
The "login" programs have to wait around for logout anyway, because PAM does not work correctly if there is no session cleanup at logout, and that is where the active terminal login table record should be changed to DEAD_PROCESS
too.
It is not in fact necessary at all to use login-process on systems managed by system-manager(1), systemd, upstart, or almost all other system managers.