Linux.com

BT module in Slackware

Link to this post 19 May 11

The installed system scripts work that way because there are scripts in rc.local and rc.M stating to check the specific system scripts for executable rights prior to launching them. People cannot just drop executable scripts into the folder and expect them to work, they must first add the correct initialization scripts to the correct files. I consider this a better method than what is used by distros that use the SystemV init method in which any executable script that is placed into a runlevel folder is executed without any further modifications.

Link to this post 19 May 11

mfillpot wrote:

The installed system scripts work that way because there are scripts in rc.local and rc.M stating to check the specific system scripts for executable rights prior to launching them. People cannot just drop executable scripts into the folder and expect them to work, they must first add the correct initialization scripts to the correct files. I consider this a better method than what is used by distros that use the SystemV init method in which any executable script that is placed into a runlevel folder is executed without any further modifications.

Regular users do not have access to those folders

Anyway, I rather use Archlinux aproach with a line in rc.conf containing which scripts to run at startup ;)

Using this you avoid the "problem" you were mentioning and selection of what to run or not is a matter of editing a text file. Ya know, KISS philosofy.

Regards

Link to this post 19 May 11

The other benefit we get from that method is the ability to simply start, stop and restart a service for testing or loading of new configuration files without setting the service to launch on boot. I recommend checking out some of the script files to see what they can do to make life easier.

As for the arch method, I am still trying to get used to all of the components of arch, it has some benefits but the dependency resolution still drives me crazy.

Link to this post 19 May 11

from you people, strong healthy technical discussion, I learnt/learning a lot. I am really enjoying this site like anything

Link to this post 19 May 11

mfillpot wrote:

The other benefit we get from that method is the ability to simply start, stop and restart a service for testing or loading of new configuration files without setting the service to launch on boot. I recommend checking out some of the script files to see what they can do to make life easier.

That's the thing, you can do just the same with the Arch method.

The thing is that you achieve the same with both aproaches but I find the arch one much more human friendly than Slackware's.

Regards

Link to this post 19 May 11

mfillpot wrote:

The installed system scripts work that way because there are scripts in rc.local and rc.M stating to check the specific system scripts for executable rights prior to launching them. People cannot just drop executable scripts into the folder and expect them to work, they must first add the correct initialization scripts to the correct files. I consider this a better method than what is used by distros that use the SystemV init method in which any executable script that is placed into a runlevel folder is executed without any further modifications.

At least with Fedora/RH-based Linux, system initscripts will not be run by the system unless the proper symlinks have been generated for them for the specific runlevels in which they are supposed to run. These runlevels are defined at the top of each initscript ( e.g., "# chkconfig: - 85 15" ). So you can drop an executable script in /etc/init.d/ but it won't run until you:

a) put the proper "chkconfig" entry at the top of the script
b) run a command to create the symlinks, e.g. "chkconfig --add myService" , or create them manually

Who we are ?

The Linux Foundation is a non-profit consortium dedicated to the growth of Linux.

More About the foundation...

Frequent Questions

Join / Linux Training / Board