login-process — chain-load utility for recording login accounting entries in utmp/wtmp
login-process is a chain-loading utility that is used to
record login accounting entries in the utmp and
wtmp databases, and then (if successful) chain loads to
next-prog with the
execvp(3)
function.
Normally, the next-prog will be (or will eventually
chain-load)
login(1)
and thus be the login process so recorded.
next-prog may contain its own command line options, which login-process will ignore.
login-process makes no alteration to process state.
The function of login-process is to perform the actions that used to be performed by init(1) and getty(1), in a virtual terminal login service. In such a service, using the nosh toolset and running under service-manager(1), getty(1) is replaced by a set of simpler chain-loading tools tailored for virtual terminals that do not have a "getty" state, and the service is not spawned by or monitored by an init(1) program at all, so there is no real "init" state for a terminal either. The accounting entries produced by login-process are thus compatibility features at best.
Modern BSD operating systems have a completely new user accounting database and have no notion of "login" or "init" accounting entries at all (see utmpx(3)). There are simply no accounting database entries for terminals where no-one is currently logged in. The compatibility terminal statuses that login-process records do not exist.
This utility effectively does nothing on such operating systems, and need not be used at all.
On old System V systems, the accounting database is described by
utmpx(3).
login-process writes LOGIN_PROCESS records in
the accounting database, or INIT_PROCESS records if the
--getty command line option is used.
(The user names are, respectively, "LOGIN" and "GETTY", although most old
System V accounting utilities won't report the actual contents of the user name
field for such record types.)
The locations of the utmp and wtmp
files are derived at compile time from a system header when the utility is
built from source.
To override them at runtime, use the [--utmp-filename] and [--wtmp-filename]
options.
It always extends wtmp with the new accounting record.
It locates a record in utmp to overwrite in the
conventional manner of the
pututxline(3)
function.
This is, roughly:
It overwrites any entry that matches its own process ID. Such entries are, in normal operation, the results of earlier terminal "states" being written to the accounting database by the same login service process.
Failing that, it overwrites any entry that matches its inittab ID.
login-process is not responsible for erasing records from utmp.
Properly that is the domain of
login(1)
when the user's login shell terminates, although some old
login(1)
implementations do not do this, leading to utmp records
not being marked "dead" or erased.
Re-using the "undead" utmp records for dead processes
whose utmp records have not been cleaned up is why
login-process also matches on the
inittab ID.
Failing that, it unconditionally extends utmp with a new
record.
inittab IDs
Historically, an inittab ID was the "id" field from the record
in /etc/inittab that describes the login service.
There were, of course, several problems with that design, not the least of which is
that login services were not informed what their IDs were.
The old
getty(1)
and
login(1)
programs had to derive the ID from the terminal line name, the datum that they
were supplied, and the ID was thus strongly tied to the
terminal line name, causing problems if inittab did not
have the same ID.
login-process derives the inittab ID in
the same way, determining it from the utmp terminal line
name, unless forcibly overridden with the --id
command option.
The utmp terminal line name in turn is simply the name of
the controlling TTY name with any "/dev/" or
"/run/dev/" stripped.
The controlling TTY name is determined from the value of the TTY
environment variable, if present.
This will be the case if login-process has been invoked within a chain
that has run
vc-get-tty(1),
pty-get-tty(1),
or an equivalent
getty(1)
program.
If the environment variable is absent, the
ttyname(3)
library function is called.
When determining the inittab ID from the
utmp terminal line name:
If the terminal line name begins with "tty", "tts",
"pts", or "pty" the ID is the remainder of the string.
(So "pts/5" becomes "/5" and "tty5" becomes "5".)
If the 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.
(So "vc1/tty" becomes "vc1".)
Otherwise the ID is the string.
(So "vty/5" remains "vty/5".)
In an ideal world, the last would be the sole mechanism. This complicated song and dance is for compatibility with other programs that write to the accounting database, in particular X Window System terminal emulators that also use pseudo-terminals.