cannot run a script on bootup

[digDug]

What is the good and honorable way to run a script at boot time? The script needs to launch xinit. I got the bright idea to make a copy of the "/etc/rd2.d/S20apache" file and modify it to start xinit instead. I changed several of the paths in the script to match up with where xinit hangs out. On powerup Apache, CUPS, and MySQL start. "/etc/rd2.d/S35xinit" starts after that. Xwindows starts, but shuts down later. If I can get xinit to run, it will start Mozilla - paving the way for a touchscreen kiosk.

[digDug]

Well, /etc/r2.d/S30cupsys made a better template for starting xinit than S20apache. I made a copy of S30cupsys, named it S55xinit, and modified it to start xinit. Now Apache, CUPS, MySQL and xinit launch in sequence. Xinit always starts xterm by default, so I renamed the app and replaced it with a script named xterm. The script launches Mozilla.

Now that I have these working on a hard drive I will go back to remastering and try to get the daemons running from a CD.

[Cuddles]

Slick DigDug,

I never played around with the rc areas of the initialization...

My thought would have been to go after the /etc/init.d/bootmisc.sh script... This seems to be where "I always" go, when I need to add something... I've got a few added to the bottom, it may not be the most "graceful" or the "proper" way, but, it works...

Here is a small example of the bottom of my bootmisc.sh script:

/etc/init.d/ssh start
/etc/init.d/portmap start
/etc/init.d/nfs-kernel-server start


Again, I am sure there was an easier way, or one that is better, but, heck, this works :D

Glad to see you got it working,
Ms. Cuddles

[UnderScore]

Perhaps this might help.
From The Debian GNU/Linux FAQ - Customizing your installation of Debian GNU/Linux http://www.debian.org/doc/FAQ/ch-customizing.en.html:


10.5 Every distribution seems to have a different boot-up method. Tell me about Debian's.
Like all Unices, Debian boots up by executing the program init. The configuration file for init (which is /etc/inittab) specifies that the first script to be executed should be /etc/init.d/rcS. This script runs all of the scripts in /etc/rcS.d/ by sourcing or forking subprocess depending on their file extension to perform initialization such as to check and to mount file systems, to load modules, to start the network services, to set the clock, and to perform other initialization. Then, for compatibility, it runs the files (except those with a `.'in the filename) in /etc/rc.boot/ too. Any scripts in the latter directory are usually reserved for system administrator use, and using them in packages is deprecated.

After completing the boot process, init executes all start scripts in a directory specified by the default runlevel (this runlevel is given by the entry for id in /etc/inittab). Like most System V compatible Unices, Linux has 7 runlevels:
0 (halt the system)1 (single-user mode)2 through 5 (various multi-user modes)6 (reboot the system)
Debian systems come with id=2, which indicates that the default runlevel will be '2' when the multi-user state is entered, and the scripts in /etc/rc2.d/ will be run.

In fact, the scripts in any of the directories, /etc/rcN.d/ are just symbolic links back to scripts in /etc/init.d/. However, the names of the files in each of the /etc/rcN.d/ directories are selected to indicate the way the scripts in /etc/init.d/ will be run. Specifically, before entering any runlevel, all the scripts beginning with 'K' are run; these scripts kill services. Then all the scripts beginning with 'S' are run; these scripts start services. The two-digit number following the 'K' or 'S' indicates the order in which the script is run. Lower numbered scripts are executed first.

This approach works because the scripts in /etc/init.d/ all take an argument which can be either `start', `stop', `reload', `restart' or `force-reload' and will then do the task indicated by the argument. These scripts can be used even after a system has been booted, to control various processes.

For example, with the argument `reload' the command

/etc/init.d/sendmail reload

sends the sendmail daemon a signal to reread its configuration file.

10.6 It looks as if Debian does not use rc.local to customize the boot process; what facilities are provided?
Suppose a system needs to execute script foo on start-up, or on entry to a particular (System V) runlevel. Then the system administrator should:

Enter the script foo into the directory /etc/init.d/.Run the Debian command update-rc.d with appropriate arguments, to set up links between the (command-line-specified) directories rc?.d and /etc/init.d/foo. Here, '?' is a number from 0 through 6 and corresponds to each of the System V runlevels[list:e921a61d98]Reboot the system.[/list:u:e921a61d98]

The command update-rc.d will set up links between files in the directories rc?.d and the script in /etc/init.d/. Each link will begin with a 'S' or a 'K', followed by a number, followed by the name of the script. Scripts beginning with 'S' in /etc/rcN.d/ are executed when runlevel N is entered. Scripts beginning with a 'K' are executed when leaving runlevel N.

One might, for example, cause the script foo to execute at boot-up, by putting it in /etc/init.d/ and installing the links with update-rc.d foo defaults 19. The argument 'defaults' refers to the default runlevels, which are 2 through 5. The argument '19' ensures that foo is called before any scripts containing numbers 20 or larger.

[digDug]

Thank you very much Cuddles and UnderScore. A week ago I used Google to search knoppix.net for the word "automatically." I read a lot of posts; and although I was able to get the 'installed' daemons to run, I wasn't having any luck with custom scripts. After reading these references I can see why I wasn't able to find them. Thanks again for your help. Best of all, Google will add these posts to its cache and make it easier for the next user to find help on this topic.

[digDug]

This seems like a good place to discuss "knoppix.sh" I have been using Linux for just over a month and my experience with this mystical/mythical file has been vague. I'm not sure if I will ever use this file, but I want to make it easier for other users to find out what the file is and if it meets their purpose. Here are some questions I had: Q=Question G=Guess A=Answer

Q0. Who made knoppix.sh? And what did they make it for? (My apologies to Outlaw Star)
G0. Nice of me to start with 3 questions eh? And yes - I am too lazy to change the numbers in front of the questions.
A0. (Insert Answer Here)

Q1. What type of file is knoppix.sh? Is it binary?
G1. Looks like it is a shell script. I was able to find a complete "knoppix.sh" example posted somewhere.
A1. (Insert Answer Here)

Q2. Is there a knoppix.sh file in the Knoppix.iso?
G2. Umm no. Well I searched for it and could not find it.
A2. (Insert Answer Here)

Q3. Where should I place the knoppix.sh file?
G3. Legend says that you can put it anywhere. You must use cheat code "myconf=scan" or "config=scan" to activate it. I'm not sure which code is good or bad, new or old.
A3. (Insert Answer Here)

Q4. Is "knoppix.sh" supported in the current Knoppix distro? Am I trying to use something that has been discontinued?
G4. I mean the cheat code is in place, and "knoppix.sh" in the KNOPPIX directory, but the file is being ignored. Hmmm....
A4. (Insert Answer Here)

Q5. Can you use "knoppix.sh" with a Live CD or is it for hard drive installs only?
G5. I'm going to feel really dumb when I find out that all of these answers are in the F.A.Q.
A5. (Insert Answer Here)

Q6. Do the Knoppix remastering scripts remove "knoppix.sh" before the compressed KNOPPIX file is created?
G6. I know the scripts remove ".xinitrc" and a few other files. Just wondering.
A6. (Insert Answer Here)

Please - feel free to remove my guesses and replace it all with answers. Feel free to change/remove the questions or even add new ones.