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?

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 '11 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 '11 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 '11 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 '11 at 18:44
8

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

 $ crontab -e

 @reboot /path/to/my/command.sh
3
  • This sounds pretty interesting. Cron is a part of every desktop/server Linux that's always started?
    – Coder
    Sep 8 '11 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 '11 at 17:16
  • Do not forget the exec attrib chmod +x command.sh
    – PYK
    6 hours ago
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.

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 '11 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. Sep 8 '11 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 '17 at 14:51
2

for Debian based distros:

/etc/rc.local

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

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.

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 '11 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 '11 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.

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.

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.

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.