CentOS Study Notes-system services (daemons), centosdaemons

CentOS Study Notes-system services (daemons), centosdaemons
System Service (daemons)

For some functions, the system must provide some services (whether the system itself or the network). This service is called a service. However, the provision of services always requires the running of programs! Otherwise, how should we run it? So we call the service daemon program! For example, the program that reaches the cyclic routine job scheduling service (service) is crond daemon! This Section selects the Linux private house dish of laruence-Chapter 18th of the basic learning directory, Awareness System Service (daemons)

Main daemon categories

   
Depending on the daemon startup and management methods, daemon can be divided into two categories: stand alone, which can be started independently, and services managed in a unified manner through a super daemon, the two types of daemon are described as follows:
 

• Stand_alone: This daemon can independently start the service.

   
Literally, stand alone means "independent startup. This type of daemon can be started on its own without having to manage it through other mechanisms. After daemon is started and loaded to the memory, it will continue to occupy the memory and system resources. The biggest advantage is that stand alone daemon responds quickly when client requirements occur because services are continuously provided in the memory. Common stand alone daemon include WWW daemon (httpd) and FTP daemon (vsftpd.
 

• Super daemon: A special daemon for unified management

   
The startup method of this service is to invoke the service with a unified daemon! This special daemon is called super daemon. The early super daemon was an inetd, which was later replaced by xinetd. This mechanism is interesting because all services are not started when there is no client requirement. When there is a requirement from the client, super daemon will wake up the corresponding service. After the client's requirements are met, the wake-up service will also close and release system resources.
 

   
Advantages of this mechanism: (1) since super daemon is responsible for awakening various services, super daemon can have a security control mechanism, which is similar to the functions of the network firewall! (2) because the service is closed after the client comes online, it will not occupy system resources all the time. But what are the disadvantages? The service will be awakened only when a client is online, and the loading time of the Service to the memory needs to be taken into account. Therefore, the response time of the Service will be slower!
 

Service and Port

   
In order to unify the functions of services corresponding to the port numbers of the entire Internet, so that all hosts can use the same mechanism to provide services and request services, there is a "Communication Protocol. That is to say, some conventional services are placed on the same port number! For example, the http in the URL column requires the browser to connect to the 80 port number of the WWW server! The WWW server will also activate the httpd software in port 80 so that the two can be online!
 

   
Well! So think about it. Is there any configuration in the system that can match the service with the port number? That's/etc/services!
    
     
[Root @ www ~] # Cat/etc/services .... (Omitted above ).... ftp 21/tcpftp 21/udp fsp fspdssh 22/tcp # SSH Remote Login Protocolssh 22/udp # SSH Remote Login Protocol .... (omitted in the middle ).... http 80/tcp www-http # WorldWideWeb HTTPhttp 80/udp www-http # HyperText Transfer Protocol .... (omitted below ).... # The content of this file is arranged in the following way: # <daemon name> <port/packet protocol> <service description>
  

Daemon STARTUP script and startup Method

  
Although a daemon that provides a service is only a program, the startup of this daemon still needs to run files, configuration files, and runtime environment. For example, you can refer to the httpd Program (man httpd), which has many options and parameters! In addition, to facilitate management, distribution usually records the PID of each daemon obtained after startup in the/var/run/directory! Also, before starting these services, you may have to handle whether the environment where daemon can run smoothly is correct. What laruence wants to talk about here is that there are many things to consider about starting a daemon, not simply running a program.

  
To solve the problem mentioned above, distribution usually gives us a simple shell script to start the function. This script can be used for environment detection, configuration file analysis, PID file placement, and lock actions related to important swap file cases. You only need to run this script, the above actions are carried out in one breath, and the daemon can be started smoothly and easily!
  
So where are these daemon startup scripts (shell scripts? And where are some important configuration files stored? Basically put it in these places:

• /Etc/init. d/*: place the Startup Script
  Almost all service startup scripts on the system are placed here! In fact, this is a recognized directory. Our CentOS is actually placed in/etc/rc. d/init. d! However, there are still configuration links to/etc/init. d! Since this is a recognized directory, we recommend that you remember this directory!
• /Etc/sysconfig/*: Initialize environment configuration files for each service
  Almost all services write initialization options to this directory. For example, the Initialization Configuration of the daemon in the syslog file is written to/etc/sysconfig/syslog! The network configuration is written in the/etc/sysconfig/network file. Therefore, files in this directory are also very important;
• /Etc/xinetd. conf,/etc/xinetd. d/*: super daemon configuration file
  The main configuration file (in fact the default value) of super daemon is/etc/xinetd. conf, but as mentioned above, super daemon is only a unified management mechanism. Other daemon configurations managed by super daemon are written in/etc/xinetd. d!
• /Etc/*: configuration files of each Service
  
• /Var/lib/*: database generated by each service
  Some services that generate data write their data to the/var/lib/directory. For example, the MySQL database of the database management system is written to the/var/lib/mysql/directory by default!
• /Var/run/*: PID record of each Service Program
  Since daemon is a program, you can also use kill or killall to manage it! However, daemon usually records its PID to/var/run/to worry about affecting other programs during management! For example, the PID of the login file is recorded in the/var/run/syslogd. pid file. In this way,/etc/init. d/syslog can easily manage its own programs.

Stand alone/etc/init. d/* Start

  
I just talked about the startup scripts of almost all services on the system in/etc/init. d/bottom, the script will detect the environment, search for configuration files, load the functions provided by distribution, and determine whether the environment can run the daemon, after everything is detected and confirmed to run, use the case of shell script .... esac syntax to start, close, and observe this daemon! We can simply start the script/etc/init. d/syslog as follows:
      
[Root @ www ~] #/Etc/init. d/syslog usage:/etc/init. d/syslog {start | stop | status | restart | condrestart} # When no parameters are added, the system will tell you which parameters can be used, as shown above. Example 1: Observe the current status of syslog daemon [root @ www ~] #/Etc/init. d/syslog statussyslogd (pid 4264) is running... klogd (pid 4267) is running... # indicates that syslog manages two daemon instances. These two daemon instances are running! Example 2: re-enable syslog To read the configuration file once [root @ www ~] #/Etc/init. d/syslog restart is shutting down core RECORDER: [OK] Shutting Down System RECORDER: [OK] Starting System RECORDER: [OK] Starting core RECORDER: [OK] [root @ www ~] #/Etc/init. d/syslog statussyslogd (pid 4793) is running... klogd (pid 4796) is running... # Because it was restarted, the PID is different from the value observed for the first time! What about this?
Since the system environment has been prepared for you, it is very easy to start, close, and observe using/etc/init. d! Even so, CentOS still provides another script that can start the stand alone service, that is, the service program. In fact, the service is only a script. It can analyze the parameters after the service you issued, and then go to/etc/init according to your parameters. d/get the right service to start or stop! His syntax is like this:
[Root @ www ~] # Service [service name] (start | stop | restart |...) [root @ www ~] # Service -- status-all option and parameter: service name: that is, the name of the service to be started. It must be associated with/etc/init. d/Corresponding; start |...: that is, the work to be done by the Service. -- Status-all: lists all the service statuses of stand alone in the system. Example 3: restart crond. daemon: [root @ www ~] # Service crond restart [root @ www ~] #/Etc/init. d/crond restart # either of the two methods can be processed as needed! However, laruence prefers to use/etc/init. d/* Example 4: display the running status of all the services on the current system [root @ www ~] # Service -- status-allacpid (pid 4536) is running... anacron has stopped atd (pid 4694) is running... (omitted below )....
  

Startup Mode of Super daemon

  
In fact, Super daemon is also a stand alone service, because super daemon needs to manage other services in the future. Of course, Super daemon needs to be resident in the memory! Therefore, Super daemon is enabled in the same way as stand alone! But the other daemon he manages is not like this! You must configure to start the daemon in the configuration file. The configuration file is all files in/etc/xinetd. d. How can we know whether the services managed by super daemon have been started? You can do this:
[Root @ www ~] # Grep-I 'disable'/etc/xinetd. d /*.... (Omitted above ).... /etc/xinetd. d/rsync: disable = yes/etc/xinetd. d/tcpmux-server: disable = yes/etc/xinetd. d/time-dgram: disable = yes/etc/xinetd. d/time-stream: disable = yes
Disable indicates "cancel". Therefore, if "disable = yes" is used, the service is canceled. If it is set to "disable = no", the service is started! (There is no Super daemon software in the Minimal version. There is nothing to view)
  
For details about the super daemon configuration file, see the super daemon configuration file.

Services enabled by the System

  
Use the netstat network status observation command to check our port! He can even help us find the port Program (PID )!
      
Example 1: Find out which network services are currently enabled by the system? [Root @ www ~] # Netstat-tulpActive Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program nametcp 0 0 www. vbird. tsai: 2208 *: * LISTEN 4575/hpiodtcp 0 0 *: 737 *: * LISTEN 4371/rpc. statdtcp 0 0 *: sunrpc *: * LISTEN 4336/portmaptcp 0 0 www. vbird. tsai: ipp *: * LISTEN 4606/cupsdtcp 0 0 www. vbird. tsai: smtp *: * LISTEN 4638/sendmail: accetcp 0 0 *: ssh *: * LISTEN 4595/sshdudp 0 0 *: filenet-tms *: * 4755/avahi-daemon :.... (omitted below ).... # Check whether the host name and service name appear in the Local Address area at the top. Remember, # You can add-n to display the port number, the service name corresponds to port in/etc/services Example 2: Find all services with listening network (including socket status): [root @ www ~] # Netstat-lnpActive Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program nametcp 0 0 127.0.0.1: 2208 0.0.0.0: * LISTEN 4575/hpiod .... (omitted in the middle ).... active UNIX domain sockets (only servers) Proto RefCnt Flags Type State I-Node PID/Program name Path .... (omitted in the middle ).... unix 2 [ACC] stream listening 10624 4701/xfs/tmp /. font-unix/fs7100unix 2 [ACC] STREAM LISTE NING 12824 5015/Xorg/tmp /. x11-unix/X0unix 2 [ACC] stream listening 12770 4932/TPD-binary/tmp /. gdm_socket .... (omitted below ).... # Take a closer look. In addition to the original network listening port, the socket is displayed on it. # We can clearly know which services are started! Example 3: view all service statuses [root @ www ~] # Service -- status-all
  

Configure how to start the service immediately after startup

  
We can only use netstat to observe the daemon that has been started, and use the service command or "/etc/init. the d/* start method can only start a service immediately in the current environment. What about the restart? Does the Service continue to start automatically? At this time, we need to know how my Linux host was started?
    
From the above process, you can see that the system service can be started at startup in Step 6, in fact, the sixth step is to call different services at different operation levels! So what is the running level?
  
When we start a Linux system, we can enter different modes, which are called run level ). Different running levels have different functions and services. Currently, you have two normal running levels, one of which is run level 5 with X Window Interfaces, the other is run level 3 on the plain text interface.

• Chkconfig: Manages whether system services are started by default.

      
[Root @ www ~] # Chkconfig -- list [service name] [root @ www ~] # Chkconfig [-- level [0123456] [service name] [on | off] Option and parameter: -- list: only the current service status bar is displayed. -- level: configure a service to start (on) or close (off) at this level. Example 1: list all the services managed by chkconfig in the current system [root @ www ~] # Chkconfig -- list | moreNetworkManager 0: off 1: off 2: off 3: off 4: off 5: off 6: offacpid 0: off 1: off 2: off 3: on 4: on 5: on 6: off .... (omitted in the middle ).... yum-updatesd 0: off 1: off 2: on 3: on 4: on 5: on 6: offxinetd based services: <= chargen-dgram: off chargen-stream: off .... (omitted below ).... # You can find that the preceding table has two blocks, one with numbers such as 1, 2, and 3, and the other is managed by xinetd. That's right! From here we can find that there are stand alone and super daemon services. Example 2: shows the service currently started at run level 3 [root @ www ~] # Chkconfig -- list | grep '3: on' Example 3: Enable the atd service when the run level is 3, 4, or 5: [root @ www ~] # Chkconfig -- level 345 atd on
  

Does chkconfig easily manage the services we need? It's really convenient ~ You can easily manage super daemon services through chkconfig! In addition, You Need To Know That chkconfig is only a service that will be started by default during configuration startup, so the current status of the service is unknown. Let's take the following example to illustrate:
Example 4: first observe httpd, then check whether it is started by default, and then start it with chkconfig configuration as the default [root @ www ~] #/Etc/init. d/httpd statushttpd stopped <= [root @ www ~] # Chkconfig -- list httpdhttpd 0: off 1: off 2: off 3: off 4: off 5: off 6: off # The reason is that it is not started by default! [Root @ www ~] # Chkconfig httpd on; chkconfig -- list httpdhttpd 0: off 1: off 2: on 3: on 4: on 5: on 6: off # It is already configured as "start default start". Let's take a look at whether the service is started? [Root @ www ~] #/Etc/init. d/httpd statushttpd stopped # Ha! It's still not started! Why?
The above example 4 does not start httpd, because we didn't use/etc/init. d/httpd start! We only need to configure startup during startup! We have not restarted the service, so using chkconfig will not immediately start the service! It will not immediately shut down the service, but will only be loaded or unloaded at startup. Since chkconfig can configure whether to start or not, can we manage the startup and shutdown of super daemon? Very good! Let's look at the following cases:
Example 5: Check whether rsync is enabled. What should I do if I want to disable it? [Root @ www ~] #/Etc/init. d/rsync status-bash:/etc/init. d/rsync: No such file or directory # rsync is managed by super daemon. Therefore, you cannot use stand alone to start [root @ www ~]. # Netstat-tlup | grep rsynctcp 0 0 192.168.201.110: rsync *: * LISTEN 4618/xinetdtcp 0 0 www. vbird. tsai: rsync *: * LISTEN 4618/xinetd [root @ www ~] # Chkconfig -- list rsyncrsync on <= It is started by default! Do not start it by default. [root @ www ~] # Chkconfig rsync off; chkconfig -- list rsyncrsync off <= see it! Disabled! Now let's take a look at super daemon! [Root @ www ~] #/Etc/init. d/xinetd restart; netstat-tlup | grep rsync
    
In the last command, you will find that the original rsync is missing! In this way, can you easily start and close your super daemon management service!

• Chkconfig: Configure your own system service

      
[Root @ www ~] # Chkconfig [-- add | -- del] [service name] Option and parameter: -- add: add a service name to chkconfig for management. The service name must be in/etc/init. d/inner -- del: delete a service managed by chkconfig
    
If I write a program myself and want to make the program a system service so that chkconfig can be managed, what can I do? You only need to add the service to the script that can be managed by init, that is,/etc/init. d. For example, in/etc/init. d/create a myvbird file. This file is only a simple service example. Basically, it has no use .... the file must be as follows:
  
 
 
    
  
  
Myvbird will be started at run level 3 and 5;
    
  
  
When myvbird is started in/etc/rc. d/rc [35]. d, it starts at 80 bits and ends at 70 bits.
  
 
 
  
We will introduce the so-called ranking problem in Chapter 20th. Here you can take a look. How do you do it? You can do this:
[Root @ www ~] # Vim/etc/init. d/myvbird #! /Bin/bash # chkconfig: 35 80 70 # description: Nothing! An example echo "Nothing" is used as an exercise"
This file is fun! You can refer to the files in your system. Basically, the second line is important. Its syntax is: "chkconfig: [runlevels] [enable a proper position] [stop a proper position] ". runlevels is in different run level States. start number and stop number) in/etc/rc. d/rc [35]. in d, create a configuration method named S80myvbird and K70myvbird!
[Root @ www ~] # Chkconfig -- list myvbirdservice myvbird supports chkconfig, but is not referenced in any runlevel (run 'chkconfig -- add myvbird') # The chkconfig management mechanism has not been added! Therefore, you need to move your hands and feet to [root @ www ~]. # Chkconfig -- add myvbird; chkconfig -- list myvbirdmyvbird 0: off 1: off 2: off 3: on 4: off 5: on 6: off # Check it out! Added the chkconfig management! # Interesting! If you want to delete all the data, you can issue the following situation: [root @ www ~] # Chkconfig -- del myvbird [root @ www ~] # Rm/etc/init. d/myvbird