|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Skepticism and critical thinking is not panacea, but can help to understand the world better
|Recommended Links||Suse init scripts||Xinetd||kernel boot parameter init=/bin/bash|
|service||chkconfig||System Shutdown and Rebooting||Services activation and deactiva||How to Write Suse Init Scripts||SuSEconfig and /etc/sysconfig|
|Linux Troubleshooting||Script is broken: incomplete LSB comment, missing `Required-Start:' entry||Admin Horror Stories||Etc|
There are two widespread urban myth about init scripts. The first is that scripts on lower runlevels are executed before scripts on higher runlevel. For example if we go to level 5 that means that scripts on level 3 will be executed. This is not true -- each runlevel is completely autonomous and sequence of runlevel is poorly logical. Only scripts belonging to particular runlevel are executed.
On entering particular run-level first all K-scripts are executed in sorted order. Then all S-scripts, the scripts that start daemons that should be present on a particular run-level are executed.
System V Init – the style of init is based on concept of Runlevels and a set of special script called RC-Scripts. In addition Suse and RHEL use The Linux Standards Base (LSB), and specifically, its standards for init scripts although they interpret and use them differently
In a typical German fashion, SuSE has an over-engineered RC scripts. Probably to the extent that they can be considered to be a classic example of Christmas Tree syndrome.
Scripts in /etc/init.d are divided into two sections:
All scripts are located in /etc/init.d. Scripts for changing the runlevel are also found there, but are called through symbolic links from one of the subdirectories (/etc/init.d/rc0.d to /etc/init.d/rc6.d). This is just for clarity reasons and avoids duplicate scripts (e.g., if they are used in several runlevels).
Because every script can be executed as both a start and a stop script, these scripts must understand the parameters start and stop.
The scripts understand, in addition, the restart, reload, force-reload, and status options.
|restart||If the service is running, stop it and then restart it. If it is not running, start it.|
|reload||Reload the configuration without stopping and restarting the service.|
|force-reload||Reload the configuration if the service supports this. Otherwise, do the same as if restart had been given.|
|status||Show current status of service.|
Links in each runlevel-specific subdirectory make it possible to associate scripts with different runlevels. When installing or uninstalling packages, such links are added and removed with the help of the program insserv (or using /usr/lib/lsb/install_initd, which is a script calling this program). See the manual page of insserv for details.
Below is a short introduction to the boot and stop scripts launched first (or last, respectively) as well as an explanation of the maintaining script.
The blogd daemon is a service started by the boot and by the rc scripts before any other one. It is stopped after the actions triggered by the above scripts (running a number of subscripts, for example) are completed. The blogd daemon writes any screen output to the log file /var/log/boot.msg — but only if and when /var is mounted read-write. Otherwise, blogd buffers all screen data until /var becomes available. Further information about blogd can be obtained with man blogd.
The script boot is also responsible for starting all the scripts in /etc/init.d/boot.d with a name that starts with S. There, the file systems are checked and loop devices are configured if needed. The system time is also set. If an error occurs while automatically checking and repairing the file system, the system administrator can intervene after first entering the root password. Last executed is the script boot.local.
You can create your own scripts and easily integrate them into the scheme described above. For instructions about the formatting, naming, and organization of your custom scripts, refer to the specifications of the LSB and to the man pages of init, init.d, and insserv. Additionally consult the man pages of startproc and killproc.
|Creating Your Own init Scripts|
|Faulty init scripts may freeze your machine. Edit such scripts with great care and, if possible, subject them to heavy testing in the multiuser environment. Some useful information about init scripts can be found in Section 13.2. “Runlevels”.|
### BEGIN INIT INFO # Provides: FOO # Required-Start: $syslog $remote_fs # Required-Stop: $syslog $remote_fs # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Description: Start FOO to allow XY and provide YZ ### END INIT INFO
In the first line of the INFO block, after Provides:, specify the name of the program or service controlled by this init script. In the Required-Start: and Required-Stop: lines, specify all services that need to be started or stopped, respectively, before the service itself is started or stopped. This information is used later to generate the numbering of script names, as found in the runlevel directories. Under Default-Start: and Default-Stop:, specify the runlevels in which the service should automatically be started or stopped. Finally, under Description:, provide a short description of the service in question.
On the other hand, if a script already present in /etc/init.d/ should be integrated into the existing runlevel scheme, create the links in the runlevel directories right away, either with insserv or by enabling the corresponding service in the runlevel editor of YaST. Your changes are applied during the next reboot — the new service will be started automatically.
 Red Hat Linux
Red Hat as well as most of its derivatives uses runlevels like this:
- 0 - Halt
- 1 - Single user
- 2 - Not used/User definable
- 3 - Full multi-user, console logins only
- 4 - Not used/User definable
- 5 - Full multi-user, with display manager as well as console logins
- 6 - Reboot
Which services are started in which runlevels can be managed with the chkconfig tool, which keeps its configuration settings in a mildly elaborate arrangement under /etc/rc.d/. /sbin/chkconfig --list lists all the services controlled by chkconfig and whether they are on/off for each runlevel. Setting a service A controlled by chkconfig, for levels X, Y and Z is as simple as /etc/chkconfig --level XYZ A
 SUSE Linux
SUSE uses a similar setup to Red Hat:
- 0 - Halt
- 1 - Single
- 2 - Full multi-user with no networking
- 3 - Full multi-user without display manager
- 4 - Not used/User definable
- 5 - Full multi-user with display manager
- 6 - Reboot
January 11, 2006 | Linux.com
What's the first thing that you do once you've logged onto Linux? Is it to manually start up a processes such as Apache or MySQL, or even start your network connection? Or do you have to stop applications that have started up without your telling them to, and which are overloading your machine? If you have unwanted processes starting at boot time, or find yourself starting necessary services manually, let's make your life a little bit easier by introducing you the world of Linux services.
A Linux service is an application (or set of applications) that runs in the background waiting to be used, or carrying out essential tasks. I've already mentioned a couple of typical ones (Apache and MySQL). You will generally be unaware of services until you need them.
How can you tell what services are running, and more importantly, how can you set up your own?
Let's start by looking at how the system is set up, and in particular at the directory /etc/rc.d. Here you will find either a set of files named rc.0, rc.1, rc.2, rc.3, rc.4, rc.5, and rc.6, or a set of directories named rc0.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d, and rc6.d. You will also find a file named /etc/inittab. The system uses these files (and/or directories) to control the services to be started.
System V vs. BSD
In this article I'm dealing with System V (derived from AT&T System V) based distributions. This is the most common Linux init system. Another is based on BSD (Berkeley Software Distribution). What's the difference between the two? Basically BSD doesn't have any runlevels. This means that System V gives a lot more flexibility to a system administrator.
Most Linux distros put startup scripts in the rc subdirectories (rc1.d, rc2.d, etc.), whereas BSD systems house the system scripts in /etc/rc.d. Slackware's init setup is similar to BSD systems, though Slackware does have runlevels and has had System V compatibility since Slackware 7.
If you look in the file /etc/inittab you will see something like:id:5:initdefault: l0:0:wait:/etc/rc.d/rc.0 l6:6:wait:/etc/rc.d/rc.6 x1:4:wait:/etc/rc.d/rc.4
The boot process uses these parameters to identify the default runlevel and the files that will be used by that runlevel. In this example, runlevel 4 is the default and the scripts that define runlevel 5 can be found in /etc/rc.d/rc.5.
And what is a runlevel? You might assume that this refers to different levels that the system goes through during a boot up. Instead, think of the runlevel as the point at which the system is entered. Runlevel 1 is the most basic configuration (simple single user access using an text interface), while runlevel 5 is the most advanced (multi-user, networking, and a GUI front end). Runlevels 0 and 6 are used for halting and rebooting the system.
There are, however, differences between Linux distributions. For instance, Fedora uses runlevel 5 for X-based logins, whereas Slackware uses runlevel 4 to do the same job. Therefore, you should check your documentation before making any changes. This table shows a generic list of configurations (and some examples of different distros) taken from Linux - The Complete Reference (R.Peterson, Osbourne/McGraw-Hill).
Run Level Generic Fedora Core Slackware Debian 0 Halt Halt Halt Halt 1 Single-user mode Single-user mode Single-user mode Single-user mode 2 Basic multi-user mode (without networking) User definable (Unused) User definable - configured the same as runlevel 3 Multi-user mode 3 Full (text based) multi-user mode Multi-user mode Multi-user mode - default Slackware runlevel 4 Not used Not used X11 with KDM/GDM/XDM (session managers) Multi-user mode 5 Full (GUI based) multi-user mode Full multi-user mode (with an X-based login screen) - default runlevel User definable - configured the same as runlevel 3 Multi-user mode 6 Reboot Reboot Reboot Reboot
As you can see there are slight (but important) differences between Linux distributions. One thing is common between them -- if you want to change the default level, you must edit /etc/initab. You will need to be root or use sudo to edit this file, naturally.
Why would you want to change the runlevel? Normally you will only use full GUI or text multi-user mode -- runlevels 4 or 5. You'd only want runlevels 1 or 2 if you have some system problems and you want the most basic access. Runlevels 0 and 6 should never be used as a default (for obvious reasons -- you don't want the system to shutdown or reboot as soon as you turn it on). You can, of course, change mode whilst the system is running. Type
initfollowed by the required runlevel e.g.:
This will reboot the system.
The boot process, or to be more accurate the init command, will decide the runlevel to select (in the example above it's 4) and from that will decide the rc.d script files to be run. In this case either the file /etc/rc.d/rc.4 or any files in the directory /etc/rc.d/rc4.d. Let's look at an example rc.d script file. Here's the default rc.4 file for Slackware 10.2:# Try to use GNOME's gdm session manager: if [ -x /usr/bin/gdm ]; then exec /usr/bin/gdm -nodaemon fi # Not there? OK, try to use KDE's KDM session manager: if [ -x /opt/kde/bin/kdm ]; then exec /opt/kde/bin/kdm -nodaemon fi # If all you have is XDM, I guess it will have to do: if [ -x /usr/X11R6/bin/xdm ]; then exec /usr/X11R6/bin/xdm -nodaemon fi
As you would expect, since runlevel 4 is the Slackware X11 mode, the commands are all concerned with the setting up of the graphical interface.
A quick guide to the boot process
When you boot your computer, the first thing that it will do is load the bootloader -- either GRUB or LILO in most cases. The bootloader will then load the Linux kernel -- the core operating system. Next, a process called init starts. This process reads the file /etc/inittab to establish the runlevel to use. The runlevel is the start mode for the computer.
Once init knows the runlevel it will look for the appropriate files or directories as defined in /etc/initab.
Init will then either run the script files defined by /etc/initab, or run the script files in the directories defined by /etc/initab (depending on the set up of your system).
Finally, init will present you with the logon mode that you've selected.
In the other distros (such as Fedora and Debian) you'll find that the scripts to be run are actually symbolic links to files in the directory /etc/init.d -- the central repository for all startup scripts. So all you have to do is to write your startup script, place it in /etc/init.d, and then create a symbolic link to it from the appropriate runlevel directory (or runlevel file, if that's what your system uses).
For example, runlevel 2 is the default runlevel for Debian in non-GUI mode. If you're running Apache 2 on Debian, you'd find an init script for Apache 2 under /etc/init.d called apache2. A symlink, S91apache2, points to /etc/init.d/apache2 from /etc/rc2.d -- this tells init to start Apache 2 in runlevel 2, but only after other services with lower S numbers.
When the system is shut down, there is another symlink in the /etc/rc0.d and /etc/rc6.d directories (halt and reboot, respectively) that starts with a K instead of an S, which tells init to shut down the process.
If this all still sounds a bit too complicated, you can instead simply make use of the /etc/rc.d/rc.local file. This script file is run once, before all other scripts have run but before the logon prompt appears. By default it looks something like:#!/bin/bash # # /etc/rc.local - run once at boot time # Put any local setup commands in here:
You can append your instructions onto the end of the file by defining another script to be run:/root/bin/start_bb
Or you can modify rc.local by adding the commands themselves:modprobe -r uhci modprobe usb-uhci eciadsl-start iptable -F iptables -A INPUT -i ppp0 -p tcp --syb -j DROP netdate time.nist.gov
Here a USB modem is initialized, a connection set up to a broadband network, some basic security is set up, and then the local time is synchronized with a time server. You can also start Apache or MySQL:apachectl start echo "/usr/bin/mysqld_safe &" | su mysql
Note that some distros, such as Debian, do not use rc.local for startup scripts. See the Debian FAQ if you'd like to add startup scripts for Debian or Debian-derived distros.
One final thought -- in addition to startup scripts (for rc.local), try to remember to write close-down scripts to be added to rc.0 and rc.6. This ensures that your services are shut down neatly and not left in strange states when the system halts.
About shutting down -- how do you stop a service from starting when you reboot? It's just the reverse of what we've already looked at. Either edit the relevant runlevel file (comment the lines out rather than removing them) or remove the link from the runlevel directory. Note that it may not be necessary to do this manually, as many distros include tools to manage services. For example, Red Hat and Fedora use chkconfig, while Debian uses update-rc.d.
From this brief discussion, I hope you can see how useful rc.d scripts can be when it comes to controlling the services to be run on your PC. You can now add your own as required, as well as look at existing ones that you may not require and which are slowing down your logon or overloading your PC.
F**king Beagle on Suse 10
2006-03-25, 10:19 am
How do I stop it, forever. I figured out how to kill the Beagle process
that were taking up 500MB of my
memorybut there are still process
starting every night by root and suing to another uid and they never exit.
What is starting these things and how do I stop them? I can't find
anything in the rc scripts or crontabs. Short of uninstalling it where can
informationon what's starting anything related to Beagle? I can
find all kinds of information on installing and using it but nothing on
stopping it. Any pointers would be greatly appreciated.
2006-03-25, 10:19 am
Ron Albright wrote:
> How do I stop it, forever. I figured out how to kill the Beagle
> process that were taking up 500MB of my memory but there are still
> process starting every night by root and suing to another uid and
> they never exit. What is starting these things and how do I stop
> them? I can't find anything in the rc scripts or crontabs. Short of
> uninstalling it where can I find information on what's starting
> anything related to Beagle? I can find all kinds of information on
> installing and using it but nothing on stopping it. Any pointers
> would be greatly appreciated.
rpm -e beagle? It seems to be an RPM package.
2006-03-25, 10:19 am
Ron Albright wrote:
> How do I stop it, forever. I figured out how to kill the Beagle process
> that were taking up 500MB of my memory but there are still process
> starting every night by root and suing to another uid and they never exit.
> What is starting these things and how do I stop them? I can't find
> anything in the rc scripts or crontabs. Short of uninstalling it where can
> I find information on what's starting anything related to Beagle? I can
> find all kinds of information on installing and using it but nothing on
> stopping it. Any pointers would be greatly appreciated.
You need to find what is starting beagled and either induce it to quit
starting beagled or have it start beagled with "beagled
--disable-scheduler". Once beagled is running it does its own scheduling.
Best thing to do about it IMO is remove the whole package.
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: March 12, 2019