Basic knowledge about starting
When your Linux starts, the first process it displays is init. If you haven't seen the display init process before, enter:
# ps -ef | GREP INIT
I will see the PID of INIT. In short, INIT runs / etc / inittab described in the task described.
The tasks described in / etc / inittab are started after init, but other tasks are started very simple. For example, by default Red Hat's / etc / inittab sets a trap to the Ctrl-Alt-delete key, when these keys are pressed in the console mode (not XDM), run the shutdown command. When starting, the init is set based on the / etc / inittab setting option, but it will be executed when this key is happened.
The format of the inittab allows the notes to start the comment line, and the normal entries are defined by ":". Comply with the following format:
ID: Runlevel: Action: Process
ID represents the unique logo defined by the user,
Runlevel can make a combination of 0-6 or empty,
Action comes from a keyword Keyword Description INIT how to treat Process,
Process is the command to be executed.
The various keywords describing the Action field can be found in the inittab manual. Commonly used keywords, not all, UNIX platforms include these:
InitDefault - define the run level after the system starts
Wait - will be executed once (when entering the run level). The init process will wait for this process to be terminated.
Boot - Defines the process that is executed when starting.
Bootwait - Similar to boot, but init in the end of the waiting process before running
Sysinit - Defines a process to execute when boot, execute in any boot or bootwait inittab entry.
The RunLvel field indicates system status. For example, running grade 0 represents the system shutdown, and the run level 6 represents the system restart. Unfortunate things, not all Linux releases follow the same runtime definition. In Red Hat, the following is supported by default.
0. System hangs
User SINGLE-User Mode
2. Multiple users, no NFS
3. Complete multi-user Complete MultiUser Mode
4. User customize
5. X11 (XDM landing)
6. Restart
Each run level has a corresponding directory under /etc/rc.d. Such as running level 5, the directory is /etc/rc.d/rc5.d. Contains the related files of the relevant tasks that start this run level. In Red Hat, these files are generally a symbolic connection of the shell script, which can be found in /etc/rc.d/init.d.
Let's take a look at these things with a simple example, the following two examples from our inittab file:
ID: 3: INitDefault: L3: 3: Wait: /etc/rc.d/rc 3
This is typical in the Red Hat system. Once INIT is started, read / etc / inittab. From the first line, we know that init will run the run level from the run after the system starts. Once we arrive at the run level, the second line tellsin to run the script /etc/rc.d/rc 3 and wait for the termination before execution.
The RC script in the /etc/rc.d directory receives 3 as a parameter. This 3 is equivalent to running level 3. Result RC Scripts Perform all scripts in the /etc/rc.d/rc3.d directory. It first implements all KILL "Kill" Kill Process or Service) with parameter "STOP", followed, it runs all scripts that are headed by letter S, with parameter "start" launching processes or services. Finally, the execution order of the K and S scripts is based on sorting; the script named S90Mysql will be executed before S95HTTPD. The script in /etc/rc.d/rc3.d is actually a symbolic connection to files in /etc/rc.d/init.d. UNIX administrators can put files in RC3.D, and if the Red Hat's init.d directory is the first location of all scripts, then claims to logically connect to the RC * .d directory. The management of these documents is annoying, trivial. ChkConfig now takes over this thing! Red Hat's CHKCONFIG tool is designed for the symbolic connection in administrative /etc/rc.d/rc[0-6].d.
View Chkconfig Items (ENTRIES)
CHKCONFIG's binary software Under / sbin, the default permissions allow any user to execute. But users with no root privileges can only look at the current chkconfig configuration. enter
[root] # chKCONFIG --List | GREP ON
The part of the output is roughly as follows:
AMD 0: OFF 1: OFF 2: OFF 3: Off 4: on 5: on 6: Offapmd 0: Off 1: Off 2: on 3: Off 4: on 5: Off 6: Offarpwatch 0: Off 1: Off 2 : OFF 3: OFF 4: OFF 5: OFF 6: Offatd 0: Off 1: Off 2: Off 3: ON 4: ON 5: ON 6: Offautofs 0: Off 1: Off 2: Off 3: Off 4: OFF 5: OFF 6: Off 2: OFF 3: Off 4: Off 5: Off 6: Offbootparamd 0: Off 1: Off 2: Off 3: Off 4: Off 5: Off 6: OffkeyTable 0: Off 1: OFF 2: on 3: on 4: on 5: on 6: Offcrond 0: OFF 1: Off 2: on 3: on 4: on 5: on 6: Offslog 0: Off 1: Off 2: on 3: ON : on 4: on 5: on 6: OffNetfs 0: Off 1: Off 2: Off 3: on 4: on 5: on 6: Offnetwork 0: Off 1: Off 2: on 3: on 4: on 5: on 5: ON 6: OFF
At each line of output, the starting segment represents the name of the init feature in /etc/rc.d/init.d. The rest of the segment indicates the state of each running stage 0-6 of the script into each run stage. For example, Crond should start when entering run levels 2, 3, 4, 5, when entering 0, 1 and 6, stop. We can find the files ending in /etc/rc.d in /etc/rc.D to confirm the correctness of our settings:
[root] # Find /etc/rc.d -name '* crond' -Print / etc / rc.d / init.d / crond / etc / rc.d / rc0.d / k60crond / etc / rc.d / Rc1.d / k60crond / etc / rc.d / rc2.d / s40crond / etc / rc.d / rc3.d / s40crond / etc / rc.d / rc4.d / s40crond / etc / rc.d / rc5. D / S40Crond / etc / rc.d / rc6.d / k60crond
Note that each "OFF" section (0, 1, 6) of ChkConfig report, a kill script exists for each "ON" section (2, 3, 4, 5), with a START script. Next, execute a different Find command to confine the type of each discovered file: [root] # Find /etc/rc.d -name '* crond' -exec file {}; /etc/rc.d/init .d / crond: bourne shell script text/ etc / rc.d / rc0.d / k60crond: symbolic link to ../ init.d / crond / etc / rc.d / rc1.d / k60crond: Symbolic link to. ./Init.d/crone/s40crond: symbolic link to ../ Init.d / crond / etc / rc.d / rc3.d / s40crond: symbolic link to ../ Init.d / crd / etc / rc.d / rc4.d / s40crond: symbolic link to ../ init.d / crond / etc / rc.d / rc5.d / s40crond: symbolic link to ../ init. D / crond / etc / rc.d / rc6.d / k60crond: Symbolic link to ../ Init.d / crond
This indicates that crones found in Init.D are a shell script that all other files found are symbolic connections to the crred script.
Adjust the Chkconfig item
Adjusting the items of Chkconfig are almost as easy as those listed in the current settings. format:
Chkconfig [--LEVEL
For example, if we decide to prohibit Crond at the run level 2,
# chkconfig --level 2 crd Off
(ROOT Execution) will turn off crd at run level 2. Run ChkConfig --List will confirm that crones have been adjusted. Further, the following Find Command Command displays a KILL script that has been replaced in the directory rc2.d: START script:
[root] # Find /etc/rc.d -name '* crond' -Print / etc / rc.d / init.d / crond / etc / rc.d / rc0.d / k60crond / etc / rc.d / Rc1.d / k60crond / etc / rc.d / rc2.d / k60crond / etc / rc.d / rc3.d / s40crond / etc / rc.d / rc4.d / s40crond / etc / rc.d / rc5. D / S40Crond / etc / rc.d / rc6.d / k60crond
It is not that Chkconfig is not automatically prohibited or activated. It is just a simple change of symbolic connections, and the super user can use this command /etc/rc.d/init.d/crond Stop immediately prohibited CROND service. Finally, you can use a command line to activate / disable a command of multiple runs. For example, enter:
Chkconfig --levels 2345 crd on
CROND will be set to start at run levels 2, 3, 4, and 5.
Delete one
Sometimes, deleting a service is also very appropriate. For example, there is no need to import a local account on the client for Sendmail. It is not necessary to run sendmail's most daemon. In this case, I found that it is necessary to prohibit Sendmail services, reducing potential security issues, deleting sendmail from ChkConfig, entering: chkconfig --del sendmail
Below, our Find command shows that there is no symbolic connection, but sendmail's init script still has:
[root] # find /etc/rc.d -name '* sendmail' -print /etc/rc.d/init.d/sendmail
This is perfect in my opinion. The script is retained, in case sendmail needs to be implemented as a service? But all the symbols are connected. We can prohibit Sendmail services in each run level, which will place a kill script in each rc * .d subdirectory, although sendmail starts from the initialization phase, is an unnecessary task, but I have seen some systems. Administrators need to manually start service at a specific occasion. Stay the Kill script to ensure clean service.
Add a chkconfig item
So far, everything goes well, we already know how to view, adjust, and delete service using ChkConfig. Add a new service now. Look at the script below.
-------------------------------------------------- Listing 1. Oracle Script ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------- #! / bin / sh <> #chkconfig: 2345 80 05 # description: Oracle 8 Serverora_Home = / usr / home / oracle / product / 8.0.5ora_owner = Oracleif [! -f $ ora_home / bin / dbstart] Thenecho "Oracle Startup: Cannot Start" EXITFICASE "$ 1" in "start") SU- $ ora_owner -c $ ora_home / bin / dbstartsu- $ ora_owner -c "$ ora_home / bin / lsnrctl start" ;; "STOP ") SU- $ ora_owner -c $ ora_home / bin / dbshutsu- $ ora_owner -c" $ ora_home / bin / lsnrctl stop ";; eSAC ------------------ -------------------------------
With this script, Oracle 8 can start with the parameter "start" to stop with the "STOP" parameter. It meets the minimum requirement of the init script can be used in combination with the /etc/rc.d/rc script.
Put the script in /etc/rc.d/init.d and run (with root):
CHMOD X /etc/rc.d/init.d/oracle
Make your script executable. If you are worried about the normal user to see this script, you can set more stringent file permissions. As long as this script can be run as a separate script as a separate script.
Pay attention to the two lines of comments in the script:
#CHKCONFIG: 2345 80 05 # Description: Oracle 8 Server
ChkConfig needs these lines to determine how to implement the initial run level add service, how to set the priority of startup and stop order. These rows indicate the script to launch Oracle 8 services for running stages 2, 3, 4, and 5. In addition, the initiation priority will be set to 80 and stop the priority setting to 05. Now the script is in a suitable location, and there is appropriate execution permission, as well as the appropriate Chkconfig comment, we can add the init script, as root,
# chkconfig --Add Oracle.
With ChkConfig's query, we can verify our added:
[root] # chKCONFIG --List | GREP ORACLEORACLE 0: OFF 1: OFF 2: On 3: on 4: on 5: On 6: Off
Moreover, we can check how ChkConfig sets symbolic connections with standard FIND commands:
[root] # Find /etc/rc.d -name '* oracle' -Print / etc / rc.d / init.d / oracle / etc / rc.d / rc0.d / k05racle / etc / rc.d / Rc1.d / k05racle / etc / rc.d / rc2.d / s80racle / etc / rc.d / rc3.d / s80racle / etc / rc.d / rc4.d / s80racle / etc / rc.d / rc5. D / S80Oracle / etc / rc.d / rc6.d / k05racle
As needed, the name of the KILL connection contains priority 05 and the START connection contains 80. If you need to adjust priority, (e.g. We stop priority needs to be set to 03), simply adjust the CHKCONFIG note line of the Oracle Init script and run the reset command command, as shown below. Symbol connection will be renamed:
[root] # chKCONFIG ORACLE RESET [root] # Find /etc/rc.d -name '* oracle' -print / etc / rc.d / init.d / oracle / etc / rc.d / rc0.d / k03racle /etc/rc.d/rc1.d/k03racle/tc/rc.d/rc2.d/s80Oracle/tc/rc.d/rc3.d/s80OrCle/tc/rc.d/rc4.d/s80Oracle/etc /rc.d/rc5.d/s80racle/tc/rc.d/rc6.d/k03racle
Improvements in Red Hat 7
Everyone may know, inetd is replaced by xinetd in Red Hat. Moreover, the function of ChkConfig has been extended to manage some XineTd's Internet service. The example is as follows:
[root] # chKCONFIG --List ... xinetd based services: finger: onlinuxf-web: offrexec: offrlogin: Offrsh: Offstalk: Offtalk: Offtelnet: ONTFTP: OFFWWU-FTPD: ON
Forbidden a xinetd service, you may be finger, you should enter:
[root] # chkconfig finger OFF.
Very simple, huh, huh. However, there is a problem here. When the configuration has changed, the command /etc/init.d/xinetd Reload specifies that the XINETD is automatically overloaded, and is executed by ChkConfig. This script runs a KILL indicating the SIGUSR2 signal to make a "hard" reconfiguration.
What does that mean? Oh, when I test, I was discontinued by the activities provided by Xinetd (I.E., Telnet, FTP, etc.) Immediately. If you plan to start / prohibit your system in your most suitable time, it may not be a problem. As an alternative, you can adjust your /etc/init.d/xinetd script, so the Reload option sends a SIGUSR1 signal. This is a "soft" reconfiguration. This will restart your service without interrupting your existing connection. Under ChkConfig, add the XineTD service Simply add the xinetd service file to the /etc/xinetd.d directory. ChkConfig will automatically "pick up" it and make it available, manage it through the Chkconfig tool. Simple!
in conclusion
Now you have realized the benefits of the Red Hat's Chkconfig tool to manage the init script, although its function seems simple, but it saves time, which makes it a system administrator to apply the command, which is worthy of remembering.
