Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Methods of running scripts at system startup.

Share your HowTo, Documentation, Tips and Tricks. Not for support questions!.
Post Reply
Message
Author
Deb-fan
Posts: 1047
Joined: 2012-08-14 12:27
Been thanked: 4 times

Methods of running scripts at system startup.

#1 Post by Deb-fan »

Okay, well been doing a bunch of these, that being running scripts oriented how-to's and time to cover yet more methods of running a script at system startup, more appropriate for fiddling with system settings etc. Noted in other tutes many people run user scripts kept in /home/username/bin and that I favor using a .(dot)directory = .bin but anyway.

* 1. Use of /etc/rc.local (now deprecated and somewhat discouraged, though still gets done for the sake of backwards compatibility and/or people are too brain-dead or lazy to learn new(better) things, it's done via the systemd rc-local.service unit, if you're using an OS that's using systemd as the init.)On such an OS, if there's a valid rc.local file in /etc then it's executed at system start ...

If you don't have one and want to use an rc.local script, create one in /etc, make it executable ie: "chmod +x /etc/rc.local" Restart your system ... did the script make the changes and do the things you wanted ? Check ... if not check the status of the rc-local service with "systemctl status rc-local.service", is it enabled ? If not as root/sudo "sudo systemctl enable rc-local.service", reboot, check again ...

Is your rc.local script crap ? One basic way of trying to debug a script, run it in a terminal and see what happens, with or without privileges .. root/sudo as needed.

Here's an example of a valid rc.local file, it's just echo'ing some settings adjustments to 3 files pertaining to someone using the ondemand power governor on a gnu/Nix OS. The syntax is obvious though, what you put between the opening shebang #!/bin/bash and the exit 0 gets run.

Code: Select all

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

echo 30 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold

echo 5 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor

echo  25000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate

exit 0

If you have an rc.local file, you know works ... it does the things you want at system start, good let's use it with either of the following methods.

** 2. An @reboot crontab, this needs be done as root user, if you don't have a root user acct ( I generally always do) try setting the crontab after running "sudo su -", someone can also enable the root user acct with "sudo passwd root" that's up to you obviously, mentioned I have a root user acct, so I make my normal user root with "su -" and then add an @reboot crontab by typing "crontab -e" in a terminal. Scroll down to the appropriate place in the file and add the crontab ... Ends up looking as follows ... The part starting with @reboot is what I added to add the crontab I want.

Code: Select all

# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command
@reboot /bin/bash /usr/local/bin/myscript.sh
When the system boots, this crontab runs the script at that path with bash and provided it's a valid script, it'll do whatever I have it set up to do. To remove a crontab, again ... I make myself root and run "crontab -r" For system bash scripts like this /usr/local/bin is a good place to put them. It's already in user $PATH etc blahblah. Mentioned create a new script or move your rc.local script contents there, rename it as necessary or desired of course (my file at that location is named startup.sh logically enough), make it executable "chmod +x /usr/local/bin/scriptname.sh" I very much prefer naming bash scripts with the .sh extension too.

* Painfully obvious note, whether SysV or Systemd, someone needs cron installed and the cron daemon/service enabled and running at system startup for it to work. Also you can do much coolness with crontabs as root or your normal user too, though this isn't an attempt at anything in-depth on that topic ... No shortage of docs-etc on it online.

*** 3. The big daddy using a Systemd service unit file to run a script at startup, systemd gives ridiculous amounts of control over when, what unit file runs where, at what point of ie: a gnu/Nix OS's bootup. You don't want to try to fiddle with a setting for say, networking, if it isn't even setup yet or change a value in a file which hasn't even been created at the point that script runs, clearly in such circumstances it's going to fail ...

Running a script with a systemd service unit file. The place to create and put these babies is "/etc/systemd/system/nameoffile.service" In my case I'm naming the service unit startup.service, so I create a file named that at the location above as root/sudo-etc. This is the contents of this working service unit to execute a script during system bootup.

Code: Select all

[Unit]
Description=Running startup script with systemd unit

[Service]
Type=oneshot
ExecStart=/bin/bash /usr/local/bin/myscript.sh

[Install]
WantedBy=multi-user.target 
This is a REALLY basic service unit, works for what I'm doing, now going to demonstrate using more of systemd's capabilities to better control at what point this service unit runs ... Someone has MANY options, I can add more info under the [Unit] section of the service file to tell systemd when/where I want this to run, can use Requires=, or Wants= and After= or Before= whichever unit file/type. Here's some such changes to the file to do so.

Code: Select all

[Unit]
Description=Running startup script with systemd unit
Wants=multi-user.target
After=multi-user.target

[Service]
Type=simple
ExecStart=/bin/bash /usr/local/bin/myscript.sh

[Install]
WantedBy=multi-user.target 

Cool systemd notes: The Wants= means my service unit Wants the unit file I put there, it could be a lot of things, whatever is appropriate for what you're doing, After= is clearly telling systemd to run this unit after the multi-user.target unit there and WantedBy= is the unit that will pull this puppy in, the point at which this unit file will run. This is big time outside of the scope of this tute, there's plenty of quality documentation online about systemd, systemd unit files of whichever type etc. Plenty on your system/OS, look at the ones in /lib/systemd/system for examples to see how they work, what they can do. Have used both (service unit examples) successfully, both do what I want done ... Well have used all 3 of these methods successfully too. Got away from 1 and 2 because systemd is the new and improved tool for many things, why not benefit from using it ?

Finally now that I've added my systemd service unit where described, with the contents shown, I have my script in the location it's supposed to be in and it's executable. Going to run the following as root/sudo "sudo systemctl daemon-reload" and then enable my startup.service unit file so that it automatically runs when OS gets booted "sudo systemctl enable startup.service" there you have it, that service unit will run my script when OS boots from then on, until-unless I disable, mask, delete etc the unit file.

Mentioned the name of my service unit file is startup.service, I want to check what unit files run before it, I can do so with "systemctl list-dependencies --after startup.service" These are the units which ran/run before my service unit, the startup.service unit ran AFTER them, that's what the output will show me, weirdly though makes sense once you think about it, if I wanted to see which units actually ran after startup.service I'd use --before in the above command instead. Obviously you can use similar to find this info on whichever-any other systemd units. ie: "systemctl list-dependencies --after basic.target", the basic.target on a system is really early on when the system is booting/setting up. Again ... use this for any unit of interest to see what's going on with it and associated units. Point I'm trying to express here is that systemd gives a person mind-numbing levels of control over system services and other units. Also same goes for insight into seeing exactly how the system works.

Alrighty, about concludes my running scripts series. :P Hopefully clarifies some stuff or helps people do some cool things with their Debian gnu/Nix or other Nixy operating systems.
Most powerful FREE tech-support tool on the planet * HERE. *

Deb-fan
Posts: 1047
Joined: 2012-08-14 12:27
Been thanked: 4 times

Re: Methods of running scripts at system startup.

#2 Post by Deb-fan »

NOTE: See Head_on_a_stick's comment for some related-relevant info in this thread ...

http://forums.debian.net/viewtopic.php? ... 67#p727558
Most powerful FREE tech-support tool on the planet * HERE. *

Post Reply