systemd is not backwards compatible with System 5
init, only System 5
Linux System 5-style system management comprises two parts,
init which runs as process #1 and
rc which is in charge of running start and stop scripts. These are actually from two distinct packages in Debian.
init is from the sysvinit package; and
rc is usually from the sysv-rc package, but could be from the file-rc or the openrc package.
/etc/inittab is a configuration file processed by
init. systemd does not provide any backwards compatibility mechanism for this. systemd's System 5 backwards compatibility mechanism is only for System 5
rc, which runs the programs in
/etc/init.d/. (It's only for that specific flavour of
rc, moreover. systemd implements no backwards compatibility mechanism for file-rc's and openrc's configuration mechanisms.)
This is not something that is specific to systemd. Pretty much no replacement init/system manager (with just 1 exception in three decades) processes
To plumb a service in to systemd, you must use the mechanisms that it does support, namely its own service unit files and (via a generator that auto-converts into unit files) the System 5
rc configuration files in
Forget about run levels.
All of that runlevel stuff that you are working with has been declared "obsolete" on systemd Linux operating systems. There is no run level 0 or 6 to enter. They don't exist outwith a few compatibility shims.
To make a service run at shutdown, the obvious answer, given by many, is to create a service unit that is
shutdown.target. This has some subtle pitfalls, though. A better, but less obvious, answer is to create an otherwise normal service unit, with
DefaultDependencies=yes to ensure that it conflicts with the shutdown target, and put the meat of the service in
ExecStop instead of in
Don't roll your own Poor Man's Dæmon Supervisor in shell script.
Such things are always badly written.
If your "service" is simply the running of a command named "stop_server.sh", then the inference is that this is a script that stops a server under some hand-rolled shell-script service management system.
It is for these badly written, rickety, unreliable, and dangerous disasters:
You have systemd. Make use of it, and run whatever service is being run here using proper service management mechanisms. You won't need this oddball
ExecStop-only service at all if you make your actual service runnable via systemd with
DefaultDependencies=true, as systemd will handle shutting down the service at shutdown time.
Taking a Poor Man's Dæmon Supervisor in shell script that "manages" one service, and then wrapping that in a systemd service unit for a second service that one then arranges to start at shutdown, when the aim is no more than to manage the first service and have it shut down when the system is halted or powered off, is a good way to an entry in the systemd House of Horror.
The world wants you to clean your screen.
Wanting not to clear a virtual terminal between log-off and subsequent log-on is very much swimming against the tide, as Greg Wooledge and others have discovered. The presence of sensitive output from privileged users, or bosses, remaining after log-off has been a security problem for Unices (and indeed other timesharing remote-access operating systems) since the 1970s, and it takes a lot of effort to undo all of the things that people have put in to avert this problem.
- Many systems have a
clear_console command in their shell logout scripts as standard. (This is problematic in its own right, as it doesn't play well with graphical programs running on kernel virtual terminal #1, and doesn't work with any other kinds of terminals, virtual or real.)
This command has to be removed.
- The default in getty programs aimed at virtual terminals, such as
mingetty, is to clear the terminal. (It does this before log-on, meaning that terminal output can remain unerased if a TTY login service is stopped. Ironically, this functionality would have been better placed in
login, which thanks to the necessities of PAM is still running at log-off.)
--noclear option has to be deployed to disable this. This involves writing one or more unit file override files, changing the
ExecStart setting, or simply pointing
autovt@.service at a local unit file of one's own devising.
- systemd's supplied
getty@.service template service unit sets
TTYVTDisallocate=yes which instructs systemd to clear a kernel virtual terminal. (This again doesn't work with any other kinds of terminals, not even user-space virtual terminals, as partly reflected in its name.)
This too has to be removed, again with an override or a different service template pointed to by