One can write van Smoorenburg
rc scripts that do this. They end up as a
esac construct for every individual step in the script. It's unmaintainable.
This is one of the known problems with this mechanism.
To it, add the fact that van Smoorenburg
rc scripts haven't been the way to do things in Ubuntu and Fedora for years. In both cases, before they had systemd they had Upstart. Then there's the fact that van Smoorenburg
rc compatibility in systemd is switched off in Arch Linux. Thinking that a van Smoorenburg
rc script is some kind of universal minimum that everyone can run even ignoring the helper command variations is an outright mistake. You are aiming at the wrong goal.
To get just an inkling of the wide differences that you have to cater for in writing a single script for all flavours, consider that since 2014 the Debian way of writing van Smoorenburg
rc scripts is now documented to be this:
## BEGIN INIT INFO
# Provides: myvpn
# Required-Start: $network $local_fs $remote_fs
# Required-Stop: $network $local_fs $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: MY VPN service
# Description: This script starts the MY VPN Daemon
### END INIT INFO
This being a lot shorter than your script, there's room for bonus content here. Taking a rough systemd service unit …
% cat myvpn.service
Description=My VPN service
… and converting it …
% system-control convert-systemd-units --no-generation-comment ./myvpn.service
… shows what a daemontools-family service definition (in this case using the nosh toolset) would also look like:
% system-control print-service-scripts ./myvpn
run:#My VPN service
run:setenv LD_LIBRARY_PATH /opt/myvpn/lib
restart:exec true # ignore script arguments
Daemontools-family service managers can run on non-Linux operating systems, and automatic restart is even the default in this world.