login-process 1 user commands nosh login-process chain-load utility for recording obsolete login accounting entries login-process --id id next-prog 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-manager1, 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 login1 is not properly dealing with login accounting (as modern versions mostly do and should). It chain loads to next-prog with the execvp3 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-terminal1 or pty-allocate1. If the environment variable is absent, it calls the ttyname3 library function. next-prog may contain its own command line options, which login-process will ignore. login-process makes no alteration to process state. 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. 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 utmpx3 "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 login1 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-manager1, 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. 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. Jonathan de Boyne Pollard