目录
一、简介与分类
1.系统的默认运行级别
2.服务的分类
3.服务与端口
二、服务管理
1.RPM包服务管理
2.源码包服务管理
三、服务管理总结
一、简介与分类
1. 系统的运行级别
1.1 默认运行级别
系统运行级别
0 - 关机
1 - 单用户模式，主要用于系统修复，类似于windows的安全模式
2 - 不完全的命令行模式，不含NFS服务(NFS是Linux之间进行文件共享的服务)
3 - 完全的命令行模式，即标准的字符界面
4 - 系统保留
5 - 图形模式
6 - 重启1.2 相关命令
[[email protected]~]# runlevel // 查看系统运行级别
N 3
[[email protected]~]# init n // 可用 init 命令将系统运行级别修改为 n 级别
[[email protected]~]# vi /etc/inittab // 可在该文件中修改系统默认运行级别
id:3:initdefault: # 在CentOS6之前，该文件集成了很多系统启动的相关功能，之后这些相关功能便被分散到系统的各个启动配置文件中了
# 是一个 CentOS 5 和 6 的一个重大区别2. 服务的分类
2.1 服务管理
系统当中每开启一个服务，都要消耗一定资源，如果能把不需要用到的服务给关掉，则会节省系统资源，提高系统的稳定性和安全性的同时又降低了系统风险。一般我们说对系统进行优化，实际上就是对系统当中的服务进行管理。
2.2 服务分类
根据 Tony 老师的分析，我习惯用 RPM包 和 源码包 来为服务的类型做划分，这样对初学者来说更容易接受，逻辑上更容易区分。而源码包和 RPM 包的区别，在我的另一篇博客上有详细介绍，要看的话可以移步http://www.cnblogs.com/myyd/p/7868608.html
由上图我们可以看到，用 RPM 包安装的服务有可以划分为 独立的服务 和 基于xinetd的服务。
2.2.1 RPM 包的服务划分：
- 独立的服务：在系统中独立运行并占据一定系统资源服务，是直接在内存中运行的，其优势是响应速度很快，当网络上的客户端对该服务进行访问时，能快速响应；缺点是占用内存和系统相关资源。
- 基于xinetd的服务：xinetd服务实际上是一种超级守护进程，即xinetd服务作为一个进程，其管理了很多服务，这些服务并不需要被系统运行，可以直接保存在硬盘中，直到被xinetd服务调用后才进入内存中运行，这些服务就叫做基于xinetd的服务；而基于xinetd的服务被xinetd服务所管理，在客户端对此类服务进行访问时，请求先到达服务器上的xinetd服务，xinetd服务唤醒(调用)基于xinetd的服务后，再由基于xinetd的服务对客户的请求进行响应。其优点是节省内存和系统相关资源。
在我们当前的 Linux 系统中，基于xinetd的服务已经越来越少了，到了 CentOS7 基本上已经淘汰了，CentOS6 中虽然还没淘汰，但是也已经没有多少了。
2.2.2 服务的启动与自启动
服务启动与服务自启动：服务启动顾名思义就是该服务在当前系统中是已经启动了；而服务自启动则代表该服务在下次系统启动时会随着系统启动，与现在是否已经启动无关。
2.2.3 查询服务的命令
[[email protected]~]# chkconfig --list // 查看系统当前安装了哪些RPM包服务，同时可以看到这些服务的自启动状态3. 服务与端口
3.1 服务于端口的简介
在网络上，每一台主机或者服务器都对应一个或者多个 IP 地址，这些 IP 地址指定了网络设备在网络中的位置，而端口就是服务器上运行的服务，当我们使用某一台服务器上的某些服务时，就必须在指定 IP 地址的同时指定端口号。如：用户通过 IP 地址找到了某一台服务器，而该台服务器上既搭建了 http 服务，又搭建了 SMTP 和 FTP 服务，那服务器应该提供哪些服务给客户端呢？这就由端口号来决定，如果用户访问的是该 IP 上的 80 号端口，那就是网页服务。所以端口实际上就是传输层向应用层传递数据的一个接口。
常见的服务于端口的对应关系如下图所示：
- DNS 既是基于 TCP 协议，也是基于 UDP 协议，在 DNS 服务器之间进行信息同步的时候使用 TCP 协议，而在响应用户的 DNS 请求的时候用 UDP 协议
- TCP 和 UDP 是两个不同的传输层协议，两个协议都分别有 0~65535 个端口号，但是一般将某个服务分配给某个协议的某个端口后，另一个协议对应的该端口也被保留起来不对外使用了。
- 所以我们一般说服务器上的 HTTP 服务是属于 80 端口，而不会强调 HTTP 协议是基于 TCP 还是 UDP，因为大家都知道这是基于 TCP 协议的服务，而 UDP 的 80 端口没有被分配给其他服务。
以上端口只是比较常见的几个服务所对应的端口，我们说 TCP 和 UDP 都分别有 65536 个端口，那么剩下的端口都是干嘛的？一般来说 10000 以内的端口都是给系统程序预留的，10000 以上的端口可以给用户自定义使用。在 Linux 当中，/etc/services 文件对常规端口的作用全部做了罗列，如果我们不知道某个端口的作用，可以来查看这个文件或者百度。
3.2 netstat 命令
如果我们能知道系统当中开启了哪些端口，就可以知道系统运行了哪些服务。可以使用 netstat 命令来查看：
[[email protected]~]# netstat -tunlp // 会列出系统中所有已启动的服务
-t 列出 TCP 服务
-u 列出 UDP 服务
-n 用端口号来显示服务，而不是服务名
-l 列出正在监听的网络服务(不包含已经连接的网络服务)
-p 列出该服务的进程 ID
从上图我们可以看到，第一列是使用的传输层协议；第二三列是发送和缓存队列，如果数值不为 0 则表示该端口比较繁忙；第三四列是本地和对方的 IP 地址+端口号；第五行则是状态。比较有趣的是，我们发现只有 TCP 服务有 LISTEN 状态，而 UDP 没有，这是因为 TCP 是可靠传输，必须要时刻对该端口进行监听，而 UDP 则不用。
netstat -tunl 命令可以看到所有 LISTEN 的服务进程，却不能看到已经建立起了连接(ESTABLISHED)的服务进程，如果我们想要看服务器建立起了哪些连接，可以把选项中的 l 去掉或者用 netstat -an 命令
3.3 命令汇总区分
- 查看系统中所有已启动的服务：
netstat -tunl- 查看 RPM 包的服务及自启动状态：
chkconfig --list
二、服务管理
在对服务进行分类的时候，我们一共分了两大类： RPM 包服务和源码包服务，其中 RPM 包服务又分为独立的服务和基于 xinetd 的服务。我在整理 Linux 知识的博客中反复提到，源码包和 RPM 包在安装后的区别就是安装目录的不同，以此也带来了管理方法上的不同。如下图所示：
下面分别介绍这些服务的管理方法。
1. RPM 包服务管理
其实无论是源码包还是 RPM 包或者是系统命令和自己写的脚本，最原始也是最标准的启动方法是：使用绝对路径。当然了我们在执行系统命令的时候可以在任何位置操作，这是由于环境变量 PATH 的作用。
1.1 独立的服务管理
对于 RPM 包安装的独立的服务，我们有两种启动方法，第一种就是上述的使用绝对路径启动：/etc/init.d/服务名 start|stop|status|restart ；第二种方法是用 service 关键字。一般来说，用 RPM 包安装的服务，其服务名通常在后面加了一个d，如 httpd，这个d一般代表守护进程，可以简单认为 http 服务在 Linux 中就叫做 httpd。
1.1.1 独立服务的启动管理
- 对于第一种方法，我们在用 RPM 包安装独立的服务时，都会把服务的管理脚本放在
/etc/init.d/目录下，我们只需要在该目录下找到相应的服务名就能够管理该服务。这是标准的服务管理方法- 对于第二种方法，
service关键字实际上就是去搜索/etc/init.d/目录。但是service命令并不是 Linux 原生的命令，而是 Redhat 自己为了管理方便而单独开发出来的，所以只对 Redhat 系列的 Linux 起作用。
对于第一种方法，还可以使用 /etc/rc.d/init.d/ 目录来管理服务，这是因为在 Linux 最初的时候，服务的管理脚本是放在这个目录下的，后来开发者觉得这个目录太长了不好记，于是新建了一个 /etc/init.d/ 目录软链接指向 /etc/rc.d/init.d/，如下图所示：
上图梳理了 /etc/init.d/ 和 /etc/rc.d/init.d 之间的关系，同时也展示了服务自启动的原理。
1.1.2 独立服务的自启动管理
在前面我们已经介绍过了 chkconfig 命令能够查看服务的自启动信息，那我们如果想管理系统中自启动的服务呢？有三种方法。
- 使用
chkconfig命令：实际上chkconfig命令还能够修改服务的自启动信息：[[email protected]~]# chkconfig --level 2345 httpd on // 表示若系统运行在 2345 级别下，httpd 服务将会随着系统启动而开启 其中：[--level 2345] 可以省略
- 修改
/etc/rc.d/rc.local文件(推荐使用，因为源码包的自启动管理只能用此方法)：该文件实际上是系统每次开机的时候，用户登录之前最后读取的文件，会将该文件中的所有命令都执行一遍，若我们将服务的启动命令加入到该文件中，则可以让系统每次开机的时候自动启动该服务。该文件也有一个软链接/etc/rc.local。
- 使用
ntsysv命令：用图形界面的方法来实现服务的自启动管理，可以管理所有通过 RPM 包安装的服务(包括独立的服务和基于xinetd的服务)，与第一种方法共享自启动信息。Redhat 系列专有命令。[[email protected]~]# ntsysv // 进入图形界面后可以勾选某个服务，则系统会将该服务设为自启动服务(仅对当前系统级别生效)
1.2 基于 xinetd 的服务管理
要管理基于 xinetd 的服务，先安装 xinetd 软件： yum -y install xinetd。这种服务已经越来越少，万一碰到，我们只需要知道怎么使用就行了。
1.2.1 基于 xinetd 的服务的特点
- 基于 xinetd 的服务也有启动与自启动之说，但是我们将此类服务开启或关闭的同时其自启动状态也会随之开启或关闭，将此类服务的自启动状态开启或关闭的同时其当前服务也会随之开启或关闭。
- 基于 xinetd 的服务于系统运行级别无关：用
chkconfig --list命令可以看到，此类服务并没有与系统的运行级别相关联，因为此类服务的自启动级别取决于 xinetd 服务，所以我们在管理此类服务的时候不能够为其指定系统运行级别。
1.2.2 基于 xinetd 的服务的启动方法
基于 xinetd 的服务，它们的启动脚本都放在了 /etc/xinetd.d/ 目录下，若我们需要修改此类服务的启动与自启动状态，可以修改它们的启动脚本，如：
- 先
vi /etc/xinetd.d/rsync；- 再将
disable = yes改为disable = no即可将其设置为启动；- 最后重启 xinetd 程序
service xinetd restart即可开启该服务。(因为基于xinetd的服务不是独立的服务，所以不能用service rsync restart)。
1.2.3 基于 xinetd 的服务的自启动方法
因为与独立的服务一样都是 RPM 包安装的服务，所以其自启动方法与独立的服务相类似，都可以用 chkconfig rsync on 或者 ntsysv 来启动，但是不能用 service 方法来启动。
2. 源码包服务管理
2.1 源码包的启动管理
源码包的安装位置是我们在安装的时候手工指定的，在我们没有将源码包服务的启动脚本拷贝(链接)到 /etc/init.d/ 目录下之前，就不能用 service chkconfig ntsysv 等管理 RPM 包服务的命令来管理源码包服务。所以对于源码包服务，我们需要用 Linux 中最标准的调用服务的方式：绝对路径法。但是要注意，不同的源码包的启动脚本不同，需要查看源码包的安装说明，来获取脚本的启动方法。如 apache 服务的启动就是 /usr/local/apache2/bin/apachectl start。
2.2 源码包的自启动管理
因为不能用管理 RPM 包服务的命令来管理源码包服务，所以只能将启动源码包服务的命令写入 /etc/rc.d/rc.local 文件内来让系统自动启动该服务。
- 如果我强行想让
service命令能够管理源码包服务启动行为，那么我可以将源码包的启动脚本拷贝(链接)到/etc/init.d/目录下：ln -s /usr/local/apache2/bin/apachectl /etc/init.d/。- 如果我强行想让
chkconfig和ntsysv命令能够管理源码包服务自启动行为，就要比上面复杂一点：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 命令与 ntsysv 命令是共享自启动信息的，所以我们经过以上步骤，就可以用 ntsysv 命令来管理源码包服务了
三、服务管理总结
非常有用！不多说了一张图清晰明了。
