centos 初始化脚本 centos service脚本

转载

feiry 2024-04-28 14:03:54

文章标签 centos 初始化脚本 shell 开发工具运维 vim 文章分类 架构后端开发

Centos7下将Shell脚本转换为Systemctl start&stop Service

我们前面的文章介绍了Centos7+LVS+Keepalived实现Nginx的高可用性服务部署，在部署的配置中有一个脚本程序---realserver脚本程序，我们在上面的文章中介绍使用的是./realserver start 启动 & ./realseraver stop 停止来对该脚本程序进行管理，但是这样配置的话会有一个问题，就是当我们系统意外重启后，realserver的服务是无法自动启动的，所以我们需要配置自动启动程序的话，需要将该shell脚本修改为systemctl start service，当然默认的shell脚本是无法使用这样的方法去执行的，我们需要修改服务，具体见下：

我们先回顾一下上一篇我们介绍的shell脚本内容及启动方法

我们在root目录下创建了一个realserver的脚本文件

vim realserver

通过我们该配置文件就可以得知，该脚本文件定义了变量及函数；

vip=192.168.6.15

定义函数：function start() & function stop()

然后函数中调用vip的变量完成对应的操作

通过以上的信息我们就可以修改服务类型了；

我们都知道centos7下的systemctl的服务默认路径为：

cd /usr/lib/systemd/system/
ls

我们发现服务有以service结尾的，也有target结尾的。

unit 类型如下：

service ：守护进程的启动、停止、重启和重载是此类 unit 中最为明显的几个类型。

socket ：此类 unit 封装系统和互联网中的一个socket。当下，systemd支持流式, 数据报和连续包的AF\_INET,AF\_INET6,AF\_UNIXsocket 。也支持传统的 FIFOs 传输模式。每一个 socket unit 都有一个相应的服务 unit 。相应的服务在第一个“连接”进入 socket 或 FIFO 时就会启动(例如：nscd.socket 在有新连接后便启动 nscd.service)。

device ：此类 unit 封装一个存在于 Linux设备树中的设备。每一个使用 udev 规则标记的设备都将会在 systemd 中作为一个设备 unit 出现。udev 的属性设置可以作为配置设备 unit 依赖关系的配置源。

mount ：此类 unit 封装系统结构层次中的一个挂载点。

automount ：此类 unit 封装系统结构层次中的一个自挂载点。每一个自挂载 unit 对应一个已挂载的挂载 unit (需要在自挂载目录可以存取的情况下尽早挂载)。

target ：此类 unit 为其他 unit 进行逻辑分组。它们本身实际上并不做什么，只是引用其他 unit 而已。这样便可以对 unit 做一个统一的控制。(例如：multi-user.target 相当于在传统使用 SysV 的系统中运行级别5)；bluetooth.target 只有在蓝牙适配器可用的情况下才调用与蓝牙相关的服务，如：bluetooth 守护进程、obex 守护进程等）

snapshot ：与 targetunit 相似，快照本身不做什么，唯一的目的就是引用其他 unit 。

我们任意编辑一个.service的文件

我们可以编辑vim nginx.service查看对应的模板，然后修改内容来编辑

整个文件分三个部分，[Unit]·[Service]·[Install]

[Unit]：记录unit文件的通用信息。

[Service]：记录Service的信息

[Install]：安装信息。

Unit主要包含以下内容：

● Description：对本service的描述。

● Before, After：定义启动顺序，Before=xxx.service，代表本服务在xxx.service启动之前启动。After=xxx.service,代表本服务在xxx之后启动。

● Requires: 这个单元启动了，那么它“需要”的单元也会被启动; 它“需要”的单元被停止了，它自己也活不了。但是请注意，这个设定并不能控制某单元与它“需要”的单元的启动顺序（启动顺序是另外控制的），即 Systemd 不是先启动 Requires 再启动本单元，而是在本单元被激活时，并行启动两者。于是会产生争分夺秒的问题，如果 Requires 先启动成功，那么皆大欢喜; 如果 Requires 启动得慢，那本单元就会失败（Systemd 没有自动重试）。所以为了系统的健壮性，不建议使用这个标记，而建议使用 Wants 标记。可以使用多个 Requires。

● RequiresOverridable：跟 Requires 很像。但是如果这条服务是由用户手动启动的，那么 RequiresOverridable 后面的服务即使启动不成功也不报错。跟 Requires 比增加了一定容错性，但是你要确定你的服务是有等待功能的。另外，如果不由用户手动启动而是随系统开机启动，那么依然会有 Requires 面临的问题。

● Requisite：强势版本的 Requires。要是这里需要的服务启动不成功，那本单元文件不管能不能检测等不能等待都立刻就会失败。

● Wants：推荐使用。本单元启动了，它“想要”的单元也会被启动。但是启动不成功，对本单元没有影响。

● Conflicts：一个单元的启动会停止与它“冲突”的单元，反之亦然。

Service主要包含以下内容：

● Type：service的种类，包含下列几种类型：

----simple 默认，这是最简单的服务类型。意思就是说启动的程序就是主体程序，这个程序要是退出那么一切都退出。

-----forking 标准 Unix Daemon 使用的启动方式。启动程序后会调用 fork() 函数，把必要的通信频道都设置好之后父进程退出，留下守护精灵的子进程

-----oneshot种服务类型就是启动，完成，没进程了。

notify,idle类型比较少见，不介绍。

● ExecStart：服务启动时执行的命令，通常此命令就是服务的主体。

------如果你服务的类型不是 oneshot，那么它只可以接受一个命令，参数不限。

------多个命令用分号隔开，多行用 \ 跨行。

● ExecStartPre, ExecStartPost：ExecStart执行前后所调用的命令。

● ExecStop：定义停止服务时所执行的命令，定义服务退出前所做的处理。如果没有指定，使用systemctl stop xxx命令时，服务将立即被终结而不做处理。

● Restart：定义服务何种情况下重启（启动失败，启动超时，进程被终结）。可选选项：no, on-success, on-failure,on-watchdog, on-abort

● SuccessExitStatus：参考ExecStart中返回值，定义何种情况算是启动成功。

eg：SuccessExitStatus=1 2 8 SIGKILL

Install主要包含以下内容：

● WantedBy：何种情况下，服务被启用。

eg：WantedBy=multi-user.target（多用户环境下启用）

● Alias：别名

然后我们照着这个格式进行修改

我们在对应的system目录下创建一个service文件

vim realserver.service

填写以下信息：

[Unit]
Description=Realserver Service
[Service]
Type=oneshot
ExecStart=/root/real
[Install]
WantedBy=multi-user.target

保存退出后，我们需要根据上面定义的启动路径程序配置启动文件

/root/real

所以我们需要在对应的目录vim real粘贴以下命令即可

#!/bin/bash
ifconfig lo:0 192.168.6.15 netmask 255.255.255.255 broadcast 192.168.6.15
echo 1 >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 >/proc/sys/net/ipv4/conf/lo/arp_announce
echo 1 >/proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 >/proc/sys/net/ipv4/conf/all/arp_announce
echo "Real Server $(uname -n) started"