login-process 1 user commands nosh
login-process chain-load utility for recording obsolete login accounting entries
`login-process` --id id next-prog

## Description

This utility should not be used. It is not necessary at all on BSD operating systems. It is not necessary on Linux-based operating systems that are managed by system-manager 1, systemd, upstart, or almost all other system managers.

`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 mostly 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-terminal 1 or pty-allocate 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.

### Normal modern behaviour

Normally, this command simply does nothing at all. `/etc/inittab` was obsolete as of AT&T Unix System 5 Release 4. BSD operating systems never had it in the first place. 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`.

### Obsolete Unix System 5 Release 3 behaviour on Linux

In the obsolete `/etc/inittab` system the "active 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 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.

- 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, for examples:

- "`/run/dev/vc1/tty`" becomes "`vc1`".

- "`/dev/pts/5`" becomes "`/5`".

- "`/dev/tty5`" becomes "`5`".

- "`/dev/ttyv5`" becomes "`v5`".

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 login" table record should be changed to `DEAD_PROCESS` too.

#### Security

The program requires permission to read and write to the "active login" table and append (write) to the terminal login log. Lack of permission will result in the program aborting with an error.

## Author

Jonathan de Boyne Pollard