############################################################ # 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. ----------------------------------------- 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 and run your other 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 addroutes.sh README touchafile.sh myhost# cat /root/StartupScripts/README #################################################################### This directory houses all the startup scripts I need to startup on the system but because systemd sucks. I call the contents of this directory once from systemd and viola. NOW! you are backwards compatibile with initV. Instruction: - create a script that will run at startup. - put it in this directory. - on startup systemd will execute everything in this directory because of the servie you will create later at.... /usr/lib/systemd/system/mystartup.service - enable your new service Notes: - restarting means rerunning all these scripts. you may run the risk having duplicate processes. or you can build the script with a restart and run it from this directory. Security: - Not really the best but at we can have startup scripts like we are suppose to. 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 (2) Create the startup script that will be run from systemd Myhost# cat /etc/rc.d/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 READM` 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 <------------------------------ Run it after networking is up [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. 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 miniually. Allow systemd to "do one thing good". Then progress and build on that, and really, all the other replacements I saw( Update...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. ---------------------------------------------------------------------------------