init — the several init programs
A command named init is part of the AT&T System 5 Interface Definition. It is specified solely as a control utility, not as the program run by process #1. The name of the program run by process #1 is not part of the SVID, and it is not required to be the same program as the init command.
It is recommended that if you wish to retain System 5 habits at all you get into the habit of using telinit
runlevel instead of init
This is because the latter will sometimes end up invoking
/sbin/init and sometimes end up invoking
The nosh toolset's
/usr/local/sbin/init is a System 5 compatibility shim that is an alias for telinit(1).
It is not the program run by process #1, and it is the SVID init command.
/sbin/init is not always a System 5 compatibility shim, and what program it invokes varies widely.
/sbin/init is the original BSD init(8), the program run by process #1 when not using the nosh toolset's system manager.
It can also be run other than process #1, to be used as the SVID init command to an extent; but it has limited System 5 compatibility compared to telinit.
/sbin/init points to whatever program is run by process #1.
That will be the nosh package's system manager or some other toolset's system manager.
On Debian-family Linux operating systems, the (not universally implemented across all relevant packages) convention is for
/sbin/init to be a symbolic link to the actual system manager program.
Several toolsets do not provide System 5 compatibility when /sbin/init is run other than as process #1, and this is not the SVID init command.
Upstart, for example, starts up a "session init" in this situation.
Similarly, in the nosh toolset case,
/sbin/init becomes system-manager(1) as process #1 and per-user-manager(1) otherwise.
systemd, as built on some Linux operating systems, does not provide a telinit shim in /usr/lib/systemd/systemd (systemd's telinit shim being rather in its systemctl program).
None of these is designed to provide System 5 compatibility init functionality.