/etc/inittabis a thing of the past.
If you're doing anything that involves expecting the system to process
/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: System 5
init which originated the idea (including under this umbrella 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 5
(It is important to not confuse this with System 5
rc, with which they do have reasonable backwards compatibility.
init and System 5
rc are two different things.)
The writing has been on the wall for many years for
Ubuntu Linux people have been doing without it for almost 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
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.
svscanbootis 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
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.
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
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]
It is oft maintained that
/etc/inittab was harder to work with than
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
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
rmitab from IBM AIX, that would have been far less a problem.
inittab. Section 5. Ubuntu 12.04 manual pages.
William Arlofski. Clearing or Timestamping the readproctile service errors buffer. 13 useful qmail utilities. FreeBSD Rocks!
Rob Mayoff. Running svscan on Linux. dqd.com.
Russ Allbery (2014-06-04). daemontools-run: Add systemd support 752075. Debian Bug Tracking System.
Tollef Fog Heen (2014-05-11). systemd does not honour /etc/inittab. 747742. Debian Bug Tracking System.
IBM. Modifying the /etc/inittab file. System management. IBM AIX V6.1 documentation.