systemd is not backwards compatible with System 5 init, only System 5 rc.
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 /etc/inittab.
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 /etc/init.d/.
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 WantedBy the 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 ExecStart.
[Unit]
Documentation=https://unix.stackexchange.com/questions/233561/
[Service]
Type=oneshot
User=teststand
RemainAfterExit=true
ExecStart=/bin/true
ExecStop=/home/teststand/stop_server.sh
[Install]
WantedBy=multi-user.target
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: stop_server.sh stop_server.sh stop_server.sh stop_server.sh stop_server.sh stop_server.sh
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.)The --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 [email protected] at a local unit file of one's own devising.
- systemd's supplied
[email protected] 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 [email protected].
Further reading
