The Service Access Facility was introduced in AT&T Unix System 5 Release 4 in 1988.
It obsoleted the notion of init directly spawning getty processes under the control of /etc/inittab, amongst other things.
It is so largely forgotten nowadays that there has been no mention of it at all in Wikipedia for over 20 years.
Its major features, derided by some at the time as overcomplicated, will sound eerily familiar to modern ears, because they are the givens of modern service management subsystems. In retrospect, they do not seem complex at all.
It embodied the notions of monitored and individually configurable services with port monitors in charge of on-demand activation of those services. Services started with a standard environment and process state, and per-service configuration files allowed the environment and process state to be adjusted for each individual service.
It brought TUI login and socket-based servers under a single service management umbrella, handling the listening on sockets for socket-based services and the initial terminal connection negotiation and final disconnect cleanup for TUI login services. Compare early socket opening and on-demand activation in Daniel J. Bernstein's ucspi-tcp, the nosh service management toolset, s6, and systemd.
Port monitors would be auto-restarted on failure. Auto-restarting things is a feature of the daemontools family of service managers.
Spawned socket-based server programs would be given information about the connected client via environment variables.
The NLSPROVIDER, NLSADDR, NLSOPT, NLSUDATA, and MPREFIX environment variables are AT&T STREAMS-specific precursors to the more BSD-sockets-like UNIX Client-Server Program Interface.
It had a dedicated configuration language with built-in commands such as assign, cd, umask, and ulimit.
Compare the setenv, chdir, umask, and ulimit built-in commands in the nosh service management toolset for example, or the export, cd and umask built-in commands in execline.
The various configuration commands shared a common suffix: sacadm, pmadm, and ttyadm.
Compare systemctl/journalctl/loginctl from systemd, initctl from upstart, rcctl from OpenBSD, and svcadm from Solaris SMF.
What it did not do, compared to modern service management toolsets, is manage socket services that were not invoked on demand, per connection.
It also did not have facilities for services that did not fit under the "port" umbrella of a terminal device or a network connection, such as cron.
/etc/inittab contained one record to invoke the Service Access Controller, /usr/lib/saf/sac.
There were no records invoking getty against terminal devices any more.
The configuration information was not /etc/inittab records any more but various system-wide, per-port-monitor, and per-service configuration files all under /etc/saf/.
This was a three-level directory tree, with system-wide configuration at the top level, per-port-monitor configuration at the next, and per-service configuration at the level below that.
The SAC in turn spawned the port monitors.
One of those port monitors was listen which handled listening sockets.
The other was ttymon, which handled connections and disconnections across one or more terminal devices, and itself in turn spawned the TUI login sessions.
It was the SAC and the port monitors that handled updating the Unix login database.
init was not involved and had no dealings in login accounting.
Stephen A. Rago (1993). "The Service Access Facility". UNIX System V Network Programming. Addison-Wesley Professional. ISBN 9780133893014. pp. 261 et seq.
UNIX System Laboratories (1991). "Overview of the Service Access Facility". Unix System V/386, Release 4: System Administrator's Guide. Prentice-Hall. ISBN 9780139329142.
David Fiedler and Bruce H. Hunter (1991). "Service Access Controller". UNIX System V Release 4 Administration. Sams. ISBN 9780672228100.
"The Service Access Controller". The Service Access Facility. UnixWare 7. The SCO Group Inc.