Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com Sep 8 '11 at 16:54

This question came from our site for professional and enthusiast programmers.

    
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). –  ultrasawblade Sep 8 '11 at 18:44

7 Answers 7

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

share|improve this answer
    
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

There are many ways, i'd suggest using the cron sepcial string @reboot.

 $ crontab -e

 @reboot /path/to/my/command.sh
share|improve this answer
    
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

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
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. –  venomrld Sep 8 '11 at 17:28

for Debian based distros:

/etc/rc.local

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

share|improve this answer
up vote 0 down vote accepted

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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