2

I want to create a small script for my Linux system that would do some simple things on PC boot. The script is most likely going to be Python, but maybe I'll resort to C or shell.

The problem is that I'm a Windows developer, and the tutorials on the web look suspicious.

Some of them close all file descriptors, some don't, some implement restart, force-restart, some don't. With later ones seemingly being against the spec. Then there is the whole gid thing, that confuses me.

So basically, I don't know which script base I can use for a stable daemon, and which ones are works-on-my-machine-so-it's-correct type.

Then I stumbled upon http://manpages.ubuntu.com/manpages/hardy/man1/daemon.1.html which seems to be an official process that creates daemons, SAFELY. But then again, it's scripts in init.d that do the start-up, if I understand correctly, not existing processes.

Then there is "nice" which should be used for long running tasks, if I got it right, and probably some other gotchas.

So I'm lost here. Can anyone give me a few warnings, don'ts and maybe an idea where to look for the information online?

P.S. The script I'm going to call will have to call processes, does that mean the daemon will fork for each of them?

Improve this question
4
  • a daemon's just a regular process that has disconnected its i/o channels from its parent process, so it can keep running in the background. nothing special about it otherwise: en.wikipedia.org/wiki/Daemon_%28computing%29
    – Marc B
    Sep 8, 2011 at 16:41
  • If it's just going to run once on start up, it's not a daemon, it's a start up script. Unless you mean something that is going to keep running as long as the system stays up, in which case you are talking about a daemon.
    – Paul Tomblin
    Sep 8, 2011 at 16:42
  • I had a feeling every start-up script is launched through init.d and therefore has to be a daemon?
    – Coder
    Sep 8, 2011 at 16:47
  • Scripts in init.d could be daemons, but they also could just be scripts that accomplish things for a given run level, during entering the run level (S) or leaving the run level (K).
    – LawrenceC
    Sep 8, 2011 at 18:44

7 Answers 7

Reset to default
8

There are many ways; I’d suggest using the cron sepcial string @reboot.

 $ crontab -e

 @reboot /path/to/my/command.sh
Improve this answer
3
  • This sounds pretty interesting. Cron is a part of every desktop/server Linux that's always started?
    – Coder
    Sep 8, 2011 at 16:45
  • 1
    A cron implementation is present by default on every desktop/server Linux, however the mentioned @reboot rule is an addition of the Dillon cron, it was not present in the original Vixie cron. Other cron implementations may have other solutions, for example the @ rules in fcron. So first you have to check you cron implementation.
    – manatwork
    Sep 8, 2011 at 17:16
  • Do not forget the exec attrib chmod +x command.sh
    – PYK
    Oct 26, 2021 at 20:44
4

For executing your script at startup, keep your script files in the

/etc/rc#.d/

directories. Where # is the run level. In all systems run level 0 to 6 are supported. The run levels can be following:

0: Halt
1: Single User Mode
2: Basic Multi-user mode (No networking)
3: Basic text mode (multiuser)
4: Multi-user mode
5: GUI based multiuser mode
6: Reboot

These scripts get started automatically depending upon their initial letter. Scripts that begin with

S: start at system startup
K: start during system shutdown

If scripts of common name are there like

S<name>
K<name>

The script prefixed by K will run before that with S prefix.

Improve this answer
3
  • Do I need some sort of tool and dependency config to auto-generate S00-99 like for init.d? And do I symlink rc.d/myscript.sh to all rc1.d, rc2.d, rc3.d?
    – Coder
    Sep 8, 2011 at 17:09
  • 1
    No,only placing the scripts in the said directories will do the job. Nothing else needed. Well you could also consider chmod them for setting necessary execution permissions.
    – jagbandhuster
    Sep 8, 2011 at 17:28
  • I didn't get it. How do scripts that start during system shutdown (K<name>) run before those that start at system startup (S<name>)?
    – Rodrigo
    Feb 26, 2017 at 14:51
2

for Debian based distros:

/etc/rc.local

put your script name there and don't forget the full path

Improve this answer
0

.bashrc and .bash_profile are good places to start if its per user. For ubuntu you can add an upstart(if its available in hardy heron) job and configure it into your desired run level. If this was pre-upstart you can configure it into the System V boot scripts.

Improve this answer
2
  • What if I turn the PC on as a ftp server or that like where user never logs in unless it's to shut down the PC?
    – Coder
    Sep 8, 2011 at 16:46
  • Read first sentence. -If its a per user basis- . Read second sentence - integrate into desired run level configuration if not.
    – nsfyn55
    Sep 8, 2011 at 17:26
0

If you only need to do some things on startup, the best thing would be adding your own init.d script. Some crons (like fcron) also allow running jobs on startup.

Whether you write it in Python or whatever doesn't matter, as long as it's either ELF or has a hashbang (#!) on the first line, it will be treated and executed the same.

Improve this answer
0

Surprising! why nobody mentioned /etc/rc.d ? You can place your script at /etc/rc.d and these scripts are automatically run at boot time.

Improve this answer
0

Well, it seems that the new way to do things in most recent distros is to use Upstart - http://upstart.ubuntu.com/cookbook/

This should allow paralleled task execution as well as clean syntax. SystemV init procedures through init.d and rc.d are supposedly there only for backwards compatibility.

Reading through the manual seems that Upstart is very powerful and clean solution, but I still have a lot to study.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.