| Systemctl添加源码自定义系统服务，第二个php | 您所在的位置：网站首页 › php56下载 › Systemctl添加源码自定义系统服务，第二个php |
|
vm上有一个php72现编译一个56，不知道service启动文件怎么写，经过一番baidu，终于写出，贴一下参数 通过自己总结写出 贴一下我的博客https://vwlin.top/index.php/archives/68/ ```bash [Unit] Description=The PHP56 FastCGI Process Manager After=syslog.target network.target [Service] #Type=notify Type=simple group=nginx PIDFile=/usr/local/php56/run/php-fpm.pid ExecStart=/usr/local/php56/sbin/php56-fpm -y /usr/local/php56/etc/php-fpm.conf ExecReload=/bin/kill -USR2 $PIDFile PrivateTmp=false Restart=on-abort User=nginx [Install] WantedBy=multi-user.target 这里在成功前有一个问题我是通过messages日志得知的 我在php-fpm.conf里面开启了他自己的日志和PHP。pid的文件路径，所以这里就要给这三个文件权限，由于我的PHP是Nginx用户启动所以我给他Nginx所属人权限，run/php.pid这个的话 ，直接吧run目录的所属人给nginx。 多看日志才能快速的定位问题！ [[email protected] php56]# ll log/php-fpm.log -rw------- 1 nginx root 10729 Jul 17 18:08 log/php-fpm.log [[email protected] php56]# ll run/php-fpm.pid -rw-r--r-- 1 nginx nginx 5 Jul 17 18:08 run/php-fpm.pid [[email protected] php56]# ll log/ php-fpm.log slow.log.slow [[email protected] php56]# ll log/slow.log.slow -rw------- 1 nginx root 0 Jul 16 21:04 log/slow.log.slow ------------------------------------------------------------------------------------- ~~------------------------------~~ type的种类和解释： Type=oneshot 这一选项适用于只执行一项任务、随后立即退出的服务。可能需要同时设置 RemainAfterExit=yes 使得 systemd 在服务进程退出之后仍然认为服务处于激活状态。 Type=notify 与 Type=simple 相同，但约定服务会在就绪后向 systemd 发送一个信号。这一通知的实现由 libsystemd-daemon.so 提供。 Type=dbus 若以此方式启动，当指定的 BusName 出现在DBus系统总线上时，systemd认为服务就绪。 Type=idle systemd会等待所有任务处理完成后，才开始执行 idle 类型的单元。其他行为与 Type=simple 类似。 Type=forking systemd认为当该服务进程fork，且父进程退出后服务启动成功。对于常规的守护进程（daemon），除非你确定此启动方式无法满足需求，使用此类型启动即可。使用此启动类型应同时指定 PIDFile=，以便 systemd 能够跟踪服务的主进程 Type=simple （默认值） systemd认为该服务将立即启动。服务进程不会 fork 。如果该服务要启动其他服务，不要使用此类型启动，除非该服务是socket 激活型。 从上表可以看到，当类型为forking时，systemd会认为所运行当该服务本身是守护进程即本身会fork，且只有父进程退出后systemd才会退出，但由于参考例子并不是守护进程，故systemd一直处于阻塞等待状态，默认的simple无等待这一环节。 ———————————————— 原文链接：https://blog.csdn.net/Sardkit/article/details/79911925 -------------------------------------------------------------- RedHat和CentOS7版本的服务systemctl脚本存放在：/usr/lib/systemd/，有系统（system）和用户（user）之分，像需要开机不登陆就能运行的程序，存在系统服务里，即：/usr/lib/systemd/system目录下。 [Unit] Description：服务的说明，以及与其他相依 daemon 的设置，包括在什么服务之后才启动此服务等 Documentation：提供文档查询及技术支持 After：说明此 unit 是在哪个 daemon 启动之后才启动 Before：说明此 unit 是在哪个 daemon 启动之前启动 Requires：明确的定义此 unit 需要在哪个 daemon 启动后才能够启动！即如果在此项设置的前导服务没有启动，那么此 unit 就不会被启动 Wants：与 Requires 相反，规范的是这个 unit 之后还要启动什么服务 [Service] Type：（1）simple：默认值，这个 daemon 主要由 ExecStart 接的指令串来启动，启动后常驻于内存中 （2） forking：程序后台运行，由 ExecStart 启动的程序通过 spawns 延伸出其他子程序来作为此 daemon 的主要服务。原生的父程序在启动结束后就会终止运行。 传统的 unit 服务大多属于这种项目 （3）oneshot：与 simple 类似，不过这个程序在工作完毕后就结束了，不会常驻在内存中，一次性的服务 （4）dbus：与 simple 类似，但这个 daemon 必须要在取得一个 D-Bus 的名称后，才会继续运行！因此设置这个项目时，通常也要设置 BusName=" " 才行 （5）idle：与 simple 类似，要执行这个 daemon 必须要所有的工作都顺利执行完毕后才会执行，这类的 daemon 通常是开机到最后才执行即可的服务！ （6）notify：与simple一样 EnvironmentFile：可以指定启动脚本的环境配置文件！例如 sshd.service 的配置文件写入到 /etc/sysconfig/sshd 当中！也可以使用 Environment= 后面接多个不同的 Shell 变量来给予设置！ ExecStart：实际执行此 daemon 的指令或脚本程序，也可以使用 ExecStartPre （之前） 以及 ExecStartPost （之后） 两个设置，在实际启动服务前，进行额外的指令行为 ExecStop：与 systemctl stop 的执行有关，关闭此服务时所进行的指令 ExecReload：与 systemctl reload 有关的指令行为 Restart：当设置 Restart=1 时，则当此 daemon 服务终止后，会再次的启动此服务 PrivateTmp：True表示给服务分配独立的临时空间 PIDFile：服务进程号pid文件路径 RemainAfterExit：当设置为 RemainAfterExit=1 时，则当这个 daemon 所属的所有程序都终止之后，此服务会再尝试启动。这对于 Type=oneshot 的服务很有帮助！ TimeoutSec：若这个服务在启动或者是关闭时，因为某些缘故导致无法顺利“正常启动或正常结束”的情况下，则我们要等多久才进入“强制结束”的状态！ KillMode：可以是 process, control-group, none 的其中一种，如果是 process，则 daemon 终止时，只会终止主要的程序 （ExecStart 接的后面那串指令），如果是 control-group 时， 则由此 daemon 所产生的其他 control-group 的程序，也都会被关闭。如果是 none 的话，则没有程序会被关闭！ RestartSec：与 Restart 有点相关性，如果这个服务被关闭，然后需要重新启动时，要 sleep 多少时间再重新启动的。默认是 100ms （毫秒）。 [Install] WantedBy：这个设置后面接的大部分是 *.target unit ！这个 unit 本身是附挂在某个 target unit 下面！目录wants列表：/etc/systemd/system/multi-user.target.wants/redis.service Also：指出和单元一起安装或者被协助的单元，当目前这个 unit 本身被 enable 时，Also 后面接的 unit 也请 enable 的意思！也就是具有相依性的服务可以写在这里！ Alias：systemctl enable Unit时进行一个链接的别名的意思！当 systemctl enable 相关的服务时，则此服务会进行链接文件的创建！ Redis服务systemctl脚本。 配置完，重启systemctl：systemctl daemon-reload ————————————————下面是别写的redis启动文件 /usr/lib/systemd/system/redis.service. [Unit] Description=Redis server daemon After=network.target [Service] user=redis group=redis Type=simple ExecStart=/usr/local/redis/bin/redis-server /usr/local/redis/conf/redis.conf ExecStop=/usr/local/redis/bin/redis-cli shutdown RestartSec=42s [Install] WantedBy=multi-user.target 原文链接：https://blog.csdn.net/qq_36586867/article/details/81632115 ~~---------------------------------------------------------------------~~ Systemd的Unit文件 在 Systemd 的生态圈中（除了 CoreOS 外，目前的主流 Linux 系统，如 Arch、SUSE、Fedora、RedHat/CentOS 也都已经使用了 Systemd，此外 Ubuntu 也将最快于15.04版本启用 Systemd 作为默认的系统管理工具），Unit 文件统一了过去各种不同的系统资源配置格式，例如服务的启/停、定时任务、设备自动挂载、网络配置、设备配置、虚拟内存配置等。而 Systemd 通过不同的通过文件的后缀名来区分这些配置文件，之前我们写的 .service 文件便是其中的一种。 每一个服务以.service结尾，一般会分为3部分：[Unit]、[Service]和[Install]，我写的这个服务用于开机运行Node.js项目，简化内容如下： #[Unit]部分主要是对这个服务的说明，内容包括Description和After，Description #用于描述服务，After用于描述服务启动依赖 [Unit] Description=xiyoulibapi After=network.target remote-fs.target nss-lookup.target #[Service]部分是服务的关键，是服务的一些具体运行参数的设置，这里Type=forking #是后台运行的形式，PIDFile为存放PID的文件路径，ExecStart为服务的具体运行命令， #ExecReload为重启命令，ExecStop为停止命令，PrivateTmp=True表示给服务分配独 #立的临时空间，注意：[Service]部分的启动、重启、停止命令全部要求使用绝对路径，使 #用相对路径则会报错！ ```bash [Service] Type=forking PIDFile=/node.js/pid ExecStart=/usr/local/bin/forever start /node.js/xiyoulib/bin/www ExecReload=/usr/local/bin/forever restart /node.js/xiyoulib/bin/www ExecStop=/usr/local/bin/forever stop /node.js/xiyoulib/bin/www PrivateTmp=true #[Install]部分是服务安装的相关设置，可设置为多用户的 [Install] WantedBy=multi-user.target服务脚本按照上面编写完成后，以754的权限保存在/usr/lib/systemd/system目录下，这时就可以利用systemctl进行配置了 下面是 Systemd 所支持的12种 Unit 文件类型。 后缀名 作用 .automount 用于控制自动挂载文件系统。自动挂载即当某一目录被访问时系统自动挂载该目录，这类 unit 取代了传统 Linux 系统的 autofs 相应功能 .device 对应 /dev 目录下设备，主要用于定义设备之间的依赖关系 .mount 定义系统结构层次中的一个挂载点，可以替代过去的 /etc/fstab 配置文件 .path 用于监控指定目录变化，并触发其他 unit 运行 .scope 这类 unit 文件不是用户创建的，而是 Systemd 运行时自己产生的，描述一些系统服务的分组信息 .service 封装守护进程的启动、停止、重启和重载操作，是最常见的一种 unit 类型 .slice 用于描述 cgroup 的一些信息，极少使用到，一般用户就忽略它吧 .snapshot 这种 unit 其实是 systemctl snapshot 命令创建的一个描述 Systemd unit 运行状态的快照 .socket 监控系统或互联网中的 socket 消息，用于实现基于网络数据自动触发服务启动 .swap 定义一个用于做虚拟内存的交换分区 .target 用于对 unit 进行逻辑分组，引导其他 unit 的执行。它替代了 SysV 中运行级别的作用，并提供更灵活的基于特定设备事件的启动方式。例如 multi-user.target 相当于过去的运行级别5，而 bluetooth.target 在有蓝牙设备接入时就会被触发 .timer 封装由system的里面由时间触发的动作, 替代了 crontab 的功能 这些琳琅满目的种类，几乎囊括了系统管理的大部分的日常工作内容，一致的配置格式和操作方法使得即便普通的 Linux 系统使用者和软件开发者也能够很快的上手修改系统的配置，妈妈再也不用担心我们把系统弄挂了。其实这些配置文件类型中，真正经常需要修改的并不多，并且这篇文章只打算对其中最常用的，也是之前一直在写的 .service 类型展开说明。主要出于篇幅考虑，不过，既然格式都统一了，只要将一种配置类型用熟了，其他的配置学习来还不是分分钟的事啦 😄 需要再次强调的是，Unit 文件按照 Systemd 约定，应该被放置在指定的3个系统目录之一。这3个目录是有优先级的，依照下面表格，越靠上的优先级越高，因此在几个目录中有同名文件的时候，只有优先级最高的目录里的那个会被使用。 路径 说明 /etc/systemd/system 系统或用户提供的配置文件 /run/systemd/system 软件运行时生成的配置文件 /usr/lib/systemd/system 系统或第三方软件安装时添加的配置文件 由于这里的最后一个目录在 CoreOS 中是属于系统的只读分区，因此在 CoreOS 中，第三方软件如果安装时可能需要特别处理，将配置的 Unit 文件放到 /run/systemd/system目录中。索性 CoreOS 本来也不推荐直接在系统上安装软件，人家特意把系统分区做成只读这个意思就已经很明确了。一些确实需要安装在 CoreOS 上的软件比如 Deis，它的 .service 服务配置都是放到 /run/systemd/system目录里面的。 Service文件 开门见山，直接来看两个实际的服务配置文件吧。 第一个配置是 CoreOS 系统中 Docker 服务的 Unit 文件，路径是 /usr/lib/systemd/system/docker.service，可以看到其中的内容相当精简易读。 [Unit] Description=Docker Application Container Engine Documentation=http://docs.docker.com After=docker.socket early-docker.target network.target Requires=docker.socket early-docker.target [Service] Environment=TMPDIR=/var/tmp Environment=DOCKER_OPTS=’–insecure-registry=“0.0.0.0/0”’ EnvironmentFile=-/run/docker_opts.env LimitNOFILE=1048576 LimitNPROC=1048576 ExecStart=/usr/lib/coreos/dockerd --daemon --host=fd:// $DOCKER_OPTS [Install] WantedBy=multi-user.target第二个配置的写法风格与前一个有所差异，但同样的内容清晰，条理明确。这个配置来自 CoreOS 的一篇文档，作用是启动一个 Apache 服务容器然后将服务的运行信息注册到 Etcd 中。 （注意，这篇文档原文中的示例中似乎有一个错误，在启动 docker 时，ExecStart 中的命令参数 -p 80:80 应当为 -p 8081:80，下面代码已修正） [Unit] Description=My Advanced Service After=etcd.service After=docker.service [Service] TimeoutStartSec=0 ExecStartPre=-/usr/bin/docker kill apache1 ExecStartPre=-/usr/bin/docker rm apache1 ExecStartPre=/usr/bin/docker pull coreos/apache ExecStart=/usr/bin/docker run --name apache1 -p 8081:80 coreos/apache /usr/sbin/apache2ctl -D FOREGROUND ExecStartPost=/usr/bin/etcdctl set /domains/example.com/10.10.10.123:8081 running ExecStop=/usr/bin/docker stop apache1 ExecStopPost=/usr/bin/etcdctl rm /domains/example.com/10.10.10.123:8081 [Install] WantedBy=multi-user.target仔细观察着两个服务配置，其中有一些很明显的共同点。我们接下来就以这两个 Unit 文件为例，一步步的分析一下 Systemd 服务配置的写法。 Service 的 Unit 文件可以分为3个配置区段，其中 Unit 和 Install 段是所有 Unit 文件通用的，用于配置服务（或其他系统资源）的描述、依赖和随系统启动方式。而 Service 段则是服务类型的 Unit 文件（后缀.service）特有的，用于定义服务的具体管理和操作方法。其他的每种配置文件也都会有一个特有的配置段，这就是几种不同 Unit 配置文件最明显的区别。 来看看每个配置段常用的参数有哪些。 一、Unit 段 Description 一段描述这个 Unit 文件的文字，通常只是简短的一句话。 Documentation 指定服务的文档，可以是一个或多个文档的URL路径。 Requires 依赖的其他 Unit 列表，列在其中的 Unit 模块会在这个服务启动的同时被启动，并且如果其中有任意一个服务启动失败，这个服务也会被终止。 Wants 与 Requires 相似，但只是在被配置的这个 Unit 启动时，触发启动列出的每个 Unit 模块，而不去考虑这些模块启动是否成功。 After 与 Requires 相似，但会在后面列出的所有模块全部启动完成以后，才会启动当前的服务。 Before 与 After 相反，在启动指定的任一个模块之前，都会首先确保当前服务已经运行。 BindsTo 与 Requires 相似，但是一种更强的关联。启动这个服务时会同时启动列出的所有模块，当有模块启动失败时终止当前服务。反之，只要列出的模块全部启动以后，也会自动启动当前服务。并且这些模块中有任意一个出现意外结束或重启，这个服务会跟着终止或重启。 PartOf 这是一个 BindTo 作用的子集，仅在列出的任何模块失败或重启时，终止或重启当前服务，而不会随列出模块的启动而启动。 OnFailure 当这个模块启动失败时，就自动启动列出的每个模块。 Conflicts 与这个模块有冲突的模块，如果列出模块中有已经在运行的，这个服务就不能启动，反之亦然。 上面这些配置中，除了 Description 外，都能够被添加多次。比如前面第一个例子中的After参数在一行中使用空格分隔指定所有值，也可以像第二个例子中那样使用多个After参数，在每行参数中指定一个值。 二、Install 段 这个段中的配置与 Unit 有几分相似，但是这部分配置需要通过 systemctl enable 命令来激活，并且可以通过 systemctl disable 命令禁用。另外这部分配置的目标模块通常是特定启动级别的 .target 文件，用来使得服务在系统启动时自动运行。 WantedBy 和前面的 Wants 作用相似，只是后面列出的不是服务所依赖的模块，而是依赖当前服务的模块。 RequiredBy 和前面的 Requires 作用相似，同样后面列出的不是服务所依赖的模块，而是依赖当前服务的模块。 Also 当这个服务被 enable/disable 时，将自动 enable/disable 后面列出的每个模块。 上面的两个例子中使用的都是 “WantedBy=multi-user.target” 表明当系统以多用户方式（默认的运行级别）启动时，这个服务需要被自动运行。当然还需要 systemctl enable 激活这个服务以后自动运行才会生效。关于 Linux 系统启动时的运行级别，可以参看这篇文章。 三、Service 段 这个段是 .service 文件独有的，也是对于服务配置最重要的部分。这部分的配置选项非常多，主要分为服务生命周期控制和服务上下文配置两个方面，下面是比较常用到的一些参数。 服务生命周期控制相关的参数： Type 服务的类型，常用的有 simple（默认类型） 和 forking。默认的 simple 类型可以适应于绝大多数的场景，因此一般可以忽略这个参数的配置。而如果服务程序启动后会通过 fork 系统调用创建子进程，然后关闭应用程序本身进程的情况，则应该将 Type 的值设置为 forking，否则 systemd 将不会跟踪子进程的行为，而认为服务已经退出。 RemainAfterExit 值为 true 或 false（也可以写 yes 或 no），默认为 false。当配置值为 true 时，systemd 只会负责启动服务进程，之后即便服务进程退出了，systemd 仍然会认为这个服务是在运行中的。这个配置主要是提供给一些并非常驻内存，而是启动注册后立即退出然后等待消息按需启动的特殊类型服务使用 ExecStart 这个参数是几乎每个 .service 文件都会有的，指定服务启动的主要命令，在每个配置文件中只能使用一次。 ExecStartPre 指定在启动执行 ExecStart 的命令前的准备工作，可以有多个，如前面第二个例子中所示，所有命令会按照文件中书写的顺序依次被执行。 ExecStartPost 指定在启动执行 ExecStart 的命令后的收尾工作，也可以有多个。 TimeoutStartSec 启动服务时的等待的秒数，如果超过这个时间服务任然没有执行完所有的启动命令，则 systemd 会认为服务自动失败。这一配置对于使用 Docker 容器托管的应用十分重要，由于 Docker 第一次运行时可以能会需要从网络下载服务的镜像文件，因此造成比较严重的延时，容易被 systemd 误判为启动失败而杀死。通常对于这种服务，需要将 TimeoutStartSec 的值指定为 0，从而关闭超时检测，如前面的第二个例子。 ExecStop 停止服务所需要执行的主要命令。 ExecStopPost 指定在 ExecStop 命令执行后的收尾工作，也可以有多个。 TimeoutStopSec 停止服务时的等待的秒数，如果超过这个时间服务仍然没有停止，systemd 会使用 SIGKILL 信号强行杀死服务的进程。 Restart 这个值用于指定在什么情况下需要重启服务进程。常用的值有 no，on-success，on-failure，on-abnormal，on-abort 和 always。默认值为 no，即不会自动重启服务。这些不同的值分别表示了在哪些情况下，服务会被重新启动，参见下表。 服务退出原因 no always on-failure on-abnormal on-abort no-success 正常退出 √ √ 异常退出 √ √ 启动/停止超时 √ √ √ 被异常KILL √ √ √ √ RestartSec 如果服务需要被重启，这个参数的值为服务被重启前的等待秒数。 ExecReload 重新加载服务所需执行的主要命令。 服务上下文配置相关的参数： Environment 为服务添加环境变量，如前面的第一个例子中所示。 EnvironmentFile 指定加载一个包含服务所需的环境变量列表的文件，文件中的每一行都是一个环境变量的定义。 Nice 服务的进程优先级，值越小优先级越高，默认为0。-20为最高优先级，19为最低优先级。 WorkingDirectory 指定服务的工作目录。 RootDirectory 指定服务进程的根目录（ / 目录），如果配置了这个参数后，服务将无法访问指定目录以外的任何文件。 User 指定运行服务的用户，会影响服务对本地文件系统的访问权限。 Group 指定运行服务的用户组，会影响服务对本地文件系统的访问权限。 LimitCPU / LimitSTACK / LimitNOFILE / LimitNPROC 等 限制特定服务可用的系统资源量，例如 CPU，程序堆栈，文件句柄数量，子进程数量… 不再展开说明了，值的含义可参考 Linux 文档资源配额部分中 RLIMIT_ 开头的那些参数们。 ———————————————— 原文链接：https://blog.csdn.net/linux_yyp/article/details/106209812 |
| CopyRight 2018-2019 实验室设备网 版权所有 |