############################################################ # Searchable Keywords: systemd initv system 5 init startup # ############################################################ Summary: Everyone hates systemd but at this point no one can do anything about it. So here we are. It is suppose to be backwards compatible with init_V but, as you probably have found out, it is not. This configuration should give sys-admins tools that will get them by quickly if it is setup before you realize you need a new startup script. It's a quick way to test a startup script as well. Write, drop and reboot. Once setup. All you have to do is construct a startup script and drop it in one place( like you use to be able to do and should be able to if systemd was backwards compatible ) and reboot the system. Feb 2018 | Sept 2020 ----------------------------------------- HOW TO TURN SYSTEMD INTO INITV... almost. ----------------------------------------- 1 Create a directory in which you can dump all the scripts you want to startup at boot time. I have included a README which is sort of a how-to. 2 Create a script that systemd will execute that run all your startup scripts. 3 Create a service 4 Enable your new service. See examples below. (1) Create the directory and scripts that will be run at startup. myhost# mkdir /root/StartupScripts myhost# ls /root/StartupScripts -rwxr-xr-x 1 root root 452 Feb 21 2020 boot_nvme.sh <-------------------------------- Startup script lrwxrwxrwx 1 root root 24 Sep 3 10:49 README_startup_init_script -> /etc/rc.d/init.d/StartUp <- link to init script -rw-r--r-- 1 root root 1392 Feb 21 2020 README.txt <----------------------------------- README file lrwxrwxrwx 1 root root 41 Sep 3 10:47 README_mystartup_unit_file -> /usr/lib/systemd/system/mystartup.service <- unit file -rwxr-xr-x 1 root root 2469 Mar 31 15:51 start_boxbkup <------------------------------- Startup script Critical files: # /usr/lib/systemd/system/mystartup.service unit file or /lib/systemd/system for you Ubuntu... people. # /etc/rc.d/init.d/StartUp ------------------- Actual script to run. Must be executable === Note: Any file with READ infront of it is instructional or informational and will NOT be executed. === myhost# cat /root/StartupScripts/README #################################################################### This directory houses all the startup scripts I need to startup on the system but because systemd is less friendly. I call the contents of this directory once from systemd and viola. NOW! you are backwards compatibile with initV. I have also created symlinks to the init.d script script and the systemd unit file for handy editing. Instructions: - create a script that you want to run at startup. - Be sure it is executable. - put it in this directory. - Create a /etc/rc.d/init.d/"script to run from unit file script" or your OSes equivalent or /etc/rc.d/init.d - on startup, systemd will execute everything in this directory because of the service (unit file script) you will create later at.... /usr/lib/systemd/system/"".service - enable your new service systemctl enable "" - The init.d script can be a simple sheel script but the unit file script has a particular format. See the link in this README or the place you got this README for the format. Notes: - restarting means rerunning all these scripts. you may run the risk having duplicate processes. or you can build the script to check for duplicate processes or a restart funtion. Security: - Because we are adding an additional place to put start up scripts, we could be growing the attack surface. Although, I know of no attempts to attack this process because for one thing no one is aware of it. Security by Obsurity. - Any additional steps you feel will that will protect this diredctory is probably a good idea. Suggestions: - Make the directory you drop scripts into writable ONLY by root. - You could make it a hidden directory by putting a "." in front of the title. It is hidden unless you use the "-a" option of ls. Again, security by obsurity. - You could add some sort of auditing at startup to inventory this directory and/or checksum each script. - I find this incredibly useful and hope you do too. See this link for examples and formats: http://www.leftlogical.net/How-Tos/How-To-Turn-systemd-into-initV.html ######################################################################### Example script that could be run at startup........................ Myhost# cat touchafile.sh #!/bin/sh # # Test new startup from systemd # # touch /var/tmp/newfile`date +%m-%d-%y.S` Myhost# cat addroutes.sh #! /bin/sh # echo "Adding route 10.101.24.0/24" route add -net 10.101.24.0/22 gw 10.101.23.5 Example listing of StartupScripts directory.................... /root/StartupScripts]# ls -l total 12 -rwxr-xr-x 1 root root 452 Feb 21 13:49 boot_nvme.sh lrwxrwxrwx 1 root root 24 Feb 21 14:13 READ_init_script -> /etc/rc.d/init.d/StartUp -rw-r--r-- 1 root root 1392 Feb 21 11:59 README.txt -rwxr-xr-x 1 root root 1337 Feb 21 15:26 READ_nvme_of_startup.sh lrwxrwxrwx 1 root root 41 Feb 21 14:16 READ_sysd_unit_file -> /usr/lib/systemd/system/mystartup.service Note: Any file with READ infront of it is instructional or informational and will NOT be executed. (2) Create the startup script that will be run from systemd Red Hat derivatives/Centos path to init.d = /etc/rc.d/init.d/ Ubuntu = /etc/init.d Myhost# cat /etc/rc.d/init.d/StartUp or Ubuntu: cat /etc/init.d/startUp #!/bin/sh ###################################################################### # Gary Keen # # # One startup to rule them all # # This script will run every script in your /root/StartupScripts directory. # # ###################################################################### SCRIPTDIR=/root/StartupScripts for A in `ls $SCRIPTDIR | grep -v READ` do echo $A $SCRIPTDIR/$A done (3) Create the systemd service file. Myhost# cat /usr/lib/systemd/system/mystartup.service or /lib/systemd/system for you Ubuntu... people. [Unit] Description=My startup scripts <------------- Description After=network.target [Service] ExecStart=/etc/rc.d/init.d/StartUp & <------ The script to rule them all [Install] WantedBy=multi-user.target <----------------- Starts in multiuser but also... WantedBy=graphical.target <----------------- starts in graphical mode as well (4) Enable and start your new systemd service. Myhost# systemctl status mystartup.service Myhost# systemctl enable mystartup.service Myhost# systemctl start mystartup.service Note: - Other than the service file, the paths and locations I used could be whatever is best for your circumstances. - Because some OSes like to put things in their own locations. The location of the the mystartup.service file could have a different path( Ubuntu ). - This a very basic way of doing this and really only making it minimally useful. Please, be my guess and expand on the theme. - There is much more you can do with this. You can include your own restart of stop function and have that trigger by something else for example. - I would like to see more security added to the scripts, the directory or the execution of the scripts themselves. - You should be aware that some.... or alot of the functionality one gains from using systemd will be lost and management of the /root/StartupScripts/ and the /etc/rc.d/init.d/Startup fall to the sysadmin( in this case ). You wanted systemV , you got systemV. Whats wrong with systemd: - It is not implemented in the same way across platforms. - The /etc/rc.d/rc.d is not really backwards compatible - The commands to use systemd are not very terse. Its fine if you are a develper who just loves to type, whether its 2 in the morning or 2 in the afternoon but as sysadmin typing a command as long as your arm at 2am is not my idea of an improvment. - Complexity is the enemy of security. If there is a wide spread vuln in systemd the patch for it will have system wide implications. Introducing the question, will the patch effect the code I have written and have a service for? More on whats wrong....... http://www.zdnet.com/article/linus-torvalds-and-others-on-linuxs-systemd/ The last word: InitV needed to be updated or replaced but instead of a big bang change, start minimally. Allow systemd to "do one thing good". Then progress and build on that, and really, all the other replacements I saw( Upstart...etc ) were worse or at least severely lacking. Solaris did a similar thing when they introduced FM( fault management ) BUT ! system V is truely backwards compatible on Solaris. The scripts you ran before FM would continue to run and run from the very same place that they ran from yesterday. Never the less, and reguardless of any rant or technical observations, systemd has wide spread adoption. The time for rants, protests and complaining( I'm going to anyways )are over. My hope is that systemd will someday be the poster child for what the opensource community can do when faced with such a change that effects the use and maintenance of a system. Update: Added 01/06/2021 a script to create the directories, scripts and files to do all of the above. Systemd to systemV script. The script has been updated and upgraded over the past years. The latest, you can find here. One script to rule them all ---------------------------------------------------------------------------------