Directory
I. INTRODUCTION AND classification
1. Default operating level of the system
2. Classification of services
3. Services and Ports
Second, service management
1.RPM Package Service Management
2. Source Package Service Management
Iii. Summary of service Management
I. INTRODUCTION and Classification1. Operating level of the system1.1 Default Run Level
系统运行级别 0 - 关机 1 - 单用户模式,主要用于系统修复,类似于windows的安全模式 2 - 不完全的命令行模式,不含NFS服务(NFS是Linux之间进行文件共享的服务) 3 - 完全的命令行模式,即标准的字符界面 4 - 系统保留 5 - 图形模式 6 - 重启
1.2 Related commands
[[email protected]~]# runlevel // 查看系统运行级别N 3[[email protected]~]# init n // 可用 init 命令将系统运行级别修改为 n 级别[[email protected]~]# vi /etc/inittab // 可在该文件中修改系统默认运行级别id:3:initdefault: # 在CentOS6之前,该文件集成了很多系统启动的相关功能,之后这些相关功能便被分散到系统的各个启动配置文件中了 # 是一个 CentOS 5 和 6 的一个重大区别
2. Classification of services2.1 Service Management
In the system each open a service, must consume certain resources, if can turn off the service which does not need to use, then will save the system resources, improves the system stability and the security as well as reduces the system risk. In general, we say that the optimization of the system, in fact, is to manage the services in the system.
2.2 Service Categories
According to Tony's analysis, I'm used RPM包
to 源码包
dividing the type of service, which is easier for beginners to accept and logically easier to distinguish. and the source package and RPM package differences, in my other blog has a detailed introduction, to see the words can step http://www.cnblogs.com/myyd/p/7868608.html
As we can see, the services installed with RPM packages can be divided into 独立的服务
and 基于xinetd的服务
.
2.2.1 RPM Package Service Division:
- Stand-alone service: Run independently in the system and occupy a certain system resource service, which is run directly in memory, its advantage is that the response speed is fast, when the client on the network accesses the service, it can respond quickly; the disadvantage is that it consumes memory and system-related resources.
- XINETD-Based services: The XINETD service is actually a super daemon, that is, the XINETD service as a process, which manages a lot of services, which do not need to be run by the system, can be stored directly on the hard disk, until the XINETD service is called to run into memory, These services are called XINETD-based services, while XINETD-based services are managed by XINETD services, and when a client accesses such services, the request arrives at the XINETD service on the server, and the XINETD service wakes up (invokes) the service based on XINETD. The customer's request is then responded to by the xinetd-based service. It has the advantage of saving memory and system-related resources.
In our current Linux system, based on the XINETD service has been less and fewer, to the CentOS7 basically has been eliminated, CentOS6 although not eliminated, but there is not much.
Startup and self-booting of 2.2.2 Services
Service start-up and service start-up: The service start as the name implies is that the service is already started in the current system, and the service self-initiated on behalf of the service at the next system boot will be started with the system, regardless of whether it has been started.
2.2.3 Commands for querying services
[[email protected]~]# chkconfig --list // 查看系统当前安装了哪些RPM包服务,同时可以看到这些服务的自启动状态
3. Services and Ports3.1 Introduction to Port Service
On the network, each host or server corresponds to one or more IP addresses that specify the location of the network device in the network, and the port is the service running on the server, and when we use some services on a certain server, we must specify the port number at the same time as the IP address. Such as: The user through the IP address to find a server, and the server has built an HTTP service, and set up the SMTP and FTP services, which server should provide what services to the client? This is determined by the port number, if the user accesses the IP port number 80th, that is the Web service. So the port is actually an interface for the transport layer to pass data to the application layer.
The common service-to-port correspondence is as follows:
- DNS is both TCP-based and UDP-based, using the TCP protocol when synchronizing information between DNS servers, and using the UDP protocol in response to a user's DNS request
- TCP and UDP are two different transport layer protocols, two protocols each have 0~65535 port number, but typically a service is assigned to a port of a protocol, the other protocol corresponding to the port is also reserved for external use.
- So we generally say that the HTTP service on the server belongs to port 80, without stressing that the HTTP protocol is TCP or UDP, because it is known that this is a TCP protocol-based service, and UDP Port 80 is not assigned to other services.
To the upper port is just a few of the more common services of the corresponding ports, we say that TCP and UDP have 65,536 ports respectively, then the rest of the port is what? Generally, within 10000 of the port is reserved for the system program, more than 10000 of the port can be used to customize the user. In Linux, /etc/services
files on the role of the regular port are all listed, if we do not know the role of a port, you can check this file or Baidu.
3.2 netstat command
If we can know which ports are open in the system, we can know what services the system is running. You can use netstat
commands to view:
[[email protected]~]# netstat -tunlp // 会列出系统中所有已启动的服务 -t 列出 TCP 服务 -u 列出 UDP 服务 -n 用端口号来显示服务,而不是服务名 -l 列出正在监听的网络服务(不包含已经连接的网络服务) -p 列出该服务的进程 ID
From what we can see, the first column is the Transport layer protocol used, the 23rd column is the send and cache queue, if the value is not 0 indicates that the port is busy, the 34th column is the local and the other's IP address port number, and the second +
row is the state. Interestingly, we find that only the TCP service is LISTEN
stateful, and UDP is not, because TCP is a reliable transmission and must be monitored at all times, while UDP is not.
netstat -tunl
command can see all LISTEN
the service processes, but do not see the establishment of a connection ( ESTABLISHED
) of the service process, if we want to see the server established what connection, you can remove the option l
or use the netstat -an
command
3.3 Command Summary distinction
- To view all services that are started on the system:
netstat -tunl
- View RPM Package service and self-booting status:
chkconfig --list
second, service management
In the classification of services, we have a total of two categories: RPM Package Services and source package services, including RPM package services are divided into separate services and XINETD-based services. I have repeatedly mentioned in the blog of Linux knowledge that the difference between the source package and RPM package after installation is different from the installation directory, which also brings different management methods. As shown in the following:
The following describes how these services are managed separately.
1. RPM Package Service Management
In fact, whether it is the source package or RPM package or the system command and write their own script, the most original and most standard way to start is: using absolute path. Of course, we can operate at any location when we execute the system command, because of the environment variable PATH.
1.1 Independent service Management
For the independent service of RPM package installation, we have two starting methods, the first is the use of absolute path to start: The /etc/init.d/服务名 start|stop|status|restart
second method is to use the service
keyword. In general, the services installed with RPM packages, the service name is usually added one later d
, for example httpd
, this d
generally represents the daemon, you can simply think that the HTTP service in Linux is called httpd.
1.1.1 Start-up management for standalone services
- For the first method, when we install a standalone service with RPM packages, we place the management script of the service in the
/etc/init.d/
directory, and we only need to find the appropriate service name in that directory to manage the service. This is the standard approach to service management
- For the second method, the
service
keyword is actually to search the /etc/init.d/
directory. But the service
command is not a Linux native command, but Redhat itself developed for ease of management, so it works only with Redhat series Linux.
For the first method, you can also use the /etc/rc.d/init.d/
directory to manage the service, because at the beginning of Linux, the management script of the service was placed in this directory, and later the developer felt that the directory was too long to remember, so a new /etc/init.d/
directory soft link /etc/rc.d/init.d/
to point to, as shown in:
Combing the /etc/init.d/
/etc/rc.d/init.d
relationship between the and, but also shows the principle of service self-starting.
1.1.2 Self-starting management for standalone services
We have already introduced the chkconfig
command to view the service's self-boot information, so if we want to manage the self-initiated service in the system? There are three ways.
Use chkconfig
command: Actually chkconfig
the command can also modify the service's self-boot information:
[[email protected]~]# chkconfig --level 2345 httpd on // 表示若系统运行在 2345 级别下,httpd 服务将会随着系统启动而开启 其中:[--level 2345] 可以省略
- Modify the
/etc/rc.d/rc.local
file (recommended, because the source package of self-start management can only use this method): The file is actually the system each time you turn on, the user log in before the last read file, will be all the commands in the file will be executed once, if we add the service's start command to the file, You can start the service automatically each time the system is powered on. The file also has a soft link /etc/rc.local
.
Use the ntsysv
command: The graphical interface to implement the self-start management of the service, you can manage all the services through the RPM package installation (including independent services and XINETD-based services), and the first method of sharing the self-boot information. Redhat Series proprietary commands.
[[email protected]~]# ntsysv // 进入图形界面后可以勾选某个服务,则系统会将该服务设为自启动服务(仅对当前系统级别生效)
1.2 Service management based on XINETD
To manage xinetd-based services, install the XINETD software first: yum -y install xinetd
. This kind of service is getting smaller and fewer, and we just need to know how to use it in case it hits.
1.2.1 Features of XINETD-based services
- XINETD-based services also have start-up and self-priming, but when we turn such services on or off, their self-starting state is also turned on or off, the self-starting state of such services is turned on or off, and its current service is turned on or off.
- XINETD-based services are independent of the system RunLevel: with
chkconfig --list
commands you can see that such services are not associated with the operating level of the system, because the self-starting level of such services depends on the XINETD service, so we are not able to specify the system RunLevel when managing such services.
1.2.2 Start-up method for xinetd-based services
Based on the XINETD service, their startup scripts are placed in the /etc/xinetd.d/
directory, and if we need to modify the start-up and self-boot state of such services, they can be modified to start scripts such as:
- First
vi /etc/xinetd.d/rsync
;
- It will then be
disable = yes
disable = no
set to start;
- Finally, restart the XINETD program to
service xinetd restart
start the service. (Because XINETD-based services are not separate services, they are not available service rsync restart
).
1.2.3 Self-starting method for XINETD-based services
Since the service is installed as RPM packages as a standalone service, its self-starting method is similar to a standalone service, and can be chkconfig rsync on
started with or ntsysv
without a service
method.
2. Source Package Service Management2.1 Start-up management of source packages
Source package is installed at the time of installation we manually specified, we do not have the source package service startup script copy (link) to the /etc/init.d/
directory, you can not use service
chkconfig
ntsysv
such as management RPM Package Service command to manage the source package service. So for the source package service, we need to use the most standard method of invoking service in Linux: Absolute path method. Note, however, that different source packages have different startup scripts, and you need to look at the installation instructions for the source package to get the script startup method. If the Apache service is started /usr/local/apache2/bin/apachectl start
.
2.2 Self-starting management of source package
Because the command to manage the RPM package service cannot be used to manage the source package service, the command to start the source package service can only be written /etc/rc.d/rc.local
to the file to allow the system to start the service automatically.
- If I force the
service
command to manage the source package service startup behavior, I can copy (link) The source package's startup script to the /etc/init.d/
directory: ln -s /usr/local/apache2/bin/apachectl /etc/init.d/
.
If I forcibly wanted chkconfig
and ntsysv
ordered to be able to manage the self-priming behavior of the source package service, it would be a bit more complicated than the above:
1. [[email protected]~]# vi /etc/init.d/apachectl // 修改刚刚链接过来的启动脚本2. 往该文件中添加两句内容: 1. # chkconfig:35 86 76 2. # description:source package apachectl 其中: 第 1. 句的 chkconfig 代表将该服务加入 chkconfig 的管理;35 代表该服务的自启动的级别;86 和 76 代表启动顺序和关闭顺序 第 2. 句的内容是对第 1. 句的描述,些什么都行,但是一定要写3. [[email protected]~]# chkconfig --add apachectl // 将 apachectl 添加到 chkconfig 的管理中才能生效
chkconfig command and Ntsysv command is to share the self-boot information, so we go through the above steps, you can use the NTSYSV command to manage the source package service
Iii. Summary of service management
Very useful! Not much to say a picture clear.
Linux basic four (service management)