0

I'm trying to start a Shell Script on boot/startup I tried to edit the /etc/rc.local file, but it didn't work

#!/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.

/root/ark/startup.sh   #Added 
exit 0

It should start a script, the script alone works like a charm.(It starts a screen session...)

Any help or other methods i could use to achieve this?

1
  • What result did you want it from your shell script? You can try to add touch /home/username/test.txt on rc.local. Can you see test.txt after you rebooted? If you can see test.txt. It meant rc.local works fine.You should not change any contains on rc.local. You just added a command to run your script.
    – supriady
    Dec 27, 2016 at 14:52

2 Answers 2

Reset to default
3

Forget about rc.local.

As I said about CentOS 7:

You're using Debian 8. You have systemd. /etc/rc.local is a double backwards compatibility mechanism in systemd, because it is a backwards compatibility mechanism for a mechanism that was itself a compatibility mechanism in the van Smoorenburg System 5 rc clone.

As shown by the mess in the AskUbuntu question hyperlinked below, using /etc/rc.local can go horribly wrong. Elsewhere, people have been surprised by the fact that systemd doesn't run rc.local in the quite the same way, in quite the same place in the bootstrap, as they are used to. Others have been surprised by the fact that what they set up in rc.local expecting the old ways of doing things is then completely undone by the likes of new udev rules, NetworkManager, systemd-logind, systemd-resolved, or various "Kit"s.

Forget about rc.local. It's not the way to go. You have Debian 8. So make a proper systemd service unit, and don't begin from a point that is two levels of backwards compatibility away. (On Ubuntu, it is three times removed, the System 5 rc clone that followed it having then been itself twice superseded, over a decade ago by upstart and then by systemd.)

Don't start the process of running this with systemd by making a startup.sh script and then invoking that from a systemd service unit. That idea leads very quickly into systemd House of Horror territory. Make a service unit that describes as much as possible of the process setup and execution directly, itself. Use a wrapper shell script only when you hit the limitations of that. And make sure that your wrapper shell script at the very minimum uses exec to overlay the final dæmon program.

You don't say what that service is. You mention using screen, but that is too often abused as a Poor Man's Dæmon Supervisor and may well be not the way to run your service under an actual service manager. I do see the word "ark" in there, which in conjunction with potential abuse of screen brings to mind two things:

Further reading

2
  • I went for the legacy rc.local way. I need some time to realize that to be able to run any commands you need to explicitly export the PATH (export PATH="/bin:/usr/bin") or source the profile.
    – Zioalex
    Jan 14, 2019 at 20:20
  • 1
    there are however situations where rc.local is needed to fix a problem, and not to start a new service. the question therefore deserves an answer beyond "don't do it". in fact, for the situation i have in mind a new service would be wrong, but it's a production server where i don't have the time to solve things properly, i need to get them running first, and do them properly later. and i need rc.local for that temporary workaround.
    – eMBee
    Jun 11, 2019 at 7:13
-1

If you are using full systemd, then the standard sysvinit scripts are ignored. If you want to use sysvinit scripts you have to install systemd-shim

4
  • 1
    That's wrong in at least three ways. systemd can use van Smoorenburg rc scripts. But /etc/rc.local is not a van Smoorenburg rc script in the first place, it being from a mechanism that preceded the System 5 rc mechanism. But systemd can be made to run it, albeit with surprising results for those expecting the very old, or even just the old, behaviour.
    – JdeBP
    Dec 27, 2016 at 11:25
  • By DEFAULT systemd ignores sysvinit scripts. Tinkering around with it to get it to read van Smoorenburg rc scripts is your solution. If you want to use sysvinit scripts, I think IMHO using systemd-shim is a much better solution.
    – farhangfarhangfar
    Dec 27, 2016 at 15:39
  • And that's two further errors. There's no tinkering involved in order to use van Smoorenburg rc scripts (or indeed to use rc.local, on Debian), and what is my solution is right in front of your nose.
    – JdeBP
    Dec 27, 2016 at 19:43
  • I can see you're a real systemd fanboy, but not everyone else is. Unfortunately all the distros I use now require you to use it. But giving someone several paragraphs about that bloatware when all they want to do is add one little script to their start up is a bit much. At least Debian provides systemd-shim so that you don't have to use part of systemd and can continue to use sysvinit if it works fine for you.
    – farhangfarhangfar
    Dec 27, 2016 at 19:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .