`/etc/inittab` is a thing of the past.

If you're doing anything that involves expecting the system to process /etc/inittab, don't. /etc/inittab's day has been over for quite some time, now. It has just taken some while for people to notice.

There are only two system management subsystems that have ever supported /etc/inittab: AT&T Unix System 3 init which originated the idea (including under this umbrella AT&T Unix System 5 init, which used an updated file format, and its clones like van Smoorenbug init for Linux) and Nikola Vladov's ninit. Out of the whole range of system management subsystems from the past three decades — from Mac OS launchd through Felix von Leitner's minit, initNG, systemd, and upstart to the system-manager in nosh — no other system does, or likely will.

upstart's manual page is exceedingly stark and clear on the subject. Despite some misleading nomenclature in some systemd blurbs and doco, the same is true for systemd. Like upstart, systemd has no backwards compatibility with System 3 init. (It is important to not confuse this with System 5 rc, with which they do have reasonable backwards compatibility. System 5 init and System 5 rc are two different things.)

The writing has been on the wall for many years for /etc/inittab. Ubuntu Linux people have been doing without it for over a decade, now. Jim Caroll wrote a page explaining how to run Bernstein daemontools under upstart, because daemontools' installation program expected that the way to set itself going was to write an entry into /etc/inittab that ran svscanboot. That was in October 2006. In 2014, Gerrit Pape was hitting the same problem with Debian Linux and systemd, when Debian's turn came.

The way to run daemontools, or runit, or anything like them that expected to just install an entry into /etc/inittab and go, is to write a native job file, service unit, or whatever is appropriate to the service/system management toolset, for it.

In fact, much of /etc/inittab's functionality has been obsolete since before Linux was even invented. In Unix, run-levels have been obsolete since 1990 and all of the getty records have been obsolete since 1988.

`svscanboot` is a thing of the past, too.

The irony is that one doesn't actually need svscanboot at all with such systems. It is really /etc/inittab and old (Unix Version 7) /etc/rc specific, both of which are things of the past. It's purpose is to start up and log the output of svscan. One can do that better with the native mechanisms of the service/system management toolsets.

svscanboot, remember, is something that people were disliking back at the turn of the 21st century, and writing bodges to work around its quite substantial problems. The readproctitle "logs" weren't timestamped or rotated with age, giving no clue as to whether logged information was current information, leading to novice users frequently asking why they reported problems that they thought had been fixed; the script resulted in shell script interpreter processes running forever to no good end; and the fact that Solaris's init ran it with no standard input open led to a bug that continually terminated all managed services every ten minutes. So people recommended (e.g. Paul Jarc here and Gerrit Pape here) services that simply echoed a dot every minute, or that echoed the date; rewrote the script to use the C Shell to eliminate the extra shell processes and make things prettier and easier to locate on Linux; and bodged around its kill everything every 10 minutes problems. Doing away with it entirely is long since overdue.

Which is what one does with the native mechanisms:

Norikatsu Shigemura indicated the way in 2004 with a Mewburn rc script (only made available for FreeBSD) that replaced svscanboot entirely and ran svscan directly itself; although it still used readproctitle and still suffered from the widely experienced problems of that.
So too did Jim Caroll with upstart job files (as aforementioned), although he didn't go far enough and eliminate svscanboot entirely. upstart can arrange to log the output of svscan directly and better with a console log stanza in the job file.
A year after Caroll, Andrew George Hammond improved on the Mewburn rc script by eliminating the need for readproctitle, adding the ability to use multilog, pointed at a log directory of the system administrator's choosing, instead.
With nosh one simply runs nosh's own svscan, under nosh's service-manager; nosh separating the jobs of service scanner and service manager.
With systemd, one writes a path unit to monitor /service/ (Substitute your own directory if required. This is the standard one from the Bernstein doco.) for content and a parallel service unit to run svscan, activated by that path unit. The log from svscan goes into the systemd journal via the normal systemd route, with timestamps.
```
$ cat svscan.path
[Unit]
Description=Daemontools service monitor

[Path]
DirectoryNotEmpty=/service/
Unit=svscan.service

[Install]
WantedBy=multi-user.target
$ cat svscan.service
[Unit]
Description=Daemontools service scanner

[Service]
ExecStart=/usr/bin/svscan /service/
Restart=always

[Install]
```

Historical aside

It is oft maintained that /etc/inittab was harder to work with than /etc/init.d. One had to roll one's own update code, if one was updating it non-interactively. Of course, text file databases with one record per line and fields separated by colons are not exactly strangers to the Unix toolset, and easy to deal with with tools such as awk. But one would have had to write the awk script every time. One would also have to deal with the usual problems (shared with /etc/passwd) of safe, atomic, updates to such a critical file and locking out concurrent edit attempts.

Interestingly, had the world had noticed and cloned mkitab, chitab, lsitab, and rmitab from IBM AIX, that would have been far less a problem.

/etc/inittab is a thing of the past.

svscanboot is a thing of the past, too.

Historical aside

Further reading

`/etc/inittab` is a thing of the past.

`svscanboot` is a thing of the past, too.