陕西 做网站的公司装修设计公司有哪些
起因是redis安装systemd配置后，可以启动，但是systemctl start redis命令挂起无法退出，最后查出是因为redis的systemd配置启动类型为Type=notify，但是redis本身并没有编译为支持systemd的版本。
所以详细了解了下Type=notify。
notify启动类型举例（centos8）：
例子服务程序：notify-srv.sh
#!/bin/bashsystemd-notify --ready --status="Waiting for data…"
sleep 10do_counter=1
while : ; dosystemd-notify --status="Processing $do_counter"sleep 5do_counter=$[ $do_counter + 1 ]
done例子服务配置：notify-srv.service
[Unit]
Description=My Notify Test[Service]
Type=notify
ExecStart=/home/work/test/notify-srv.sh[Install]
WantedBy=multi-user.target安装例子服务：
chmod +x /home/work/test/notify-srv.sh
cp ./notify-srv.service /usr/lib/systemd/system/notify-srv.service
systemctl daemon-reload
测试：
可以看到status文本的变化。
其中：
1、systemd-notify --ready --status 报告服务已启动，同时发送了status文本。
2、systemd-notify --status 报告更多的状态消息。
例子服务和systemd之间的通信通过$NOTIFY_SOCKET进行，$NOTIFY_SOCKET由systemd创建，在服务启动时通过环境变量NOTIFY_SOCKET传递给服务进程。
如：
复现问题一（Type=notify，服务不支持systemd-notify）：
注释掉systemd-notify --ready --status
重启服务测试：
systemctl restart notify-srv 会挂起，不退出。
systemctl status notify-srv显示：
可以看到，和第一条status对比，由于systemd一直没有收到ready通知，所以active状态一直是start，systemctl start/restart一直不退出。但服务进程已经启动并正常运行。
复现问题二（Type=simple，服务支持systemd-notify）：
修改service的启动类型为simple：
重载配置、重启服务测试：
如上图，服务状态running，但status消息不再显示，多了“$NOTIFY_SOCKET was not set”报错，因为Type=simple启动类型并未向服务进程传递环境变量NOTIFY_SOCKET，所以systemd-notify命令报错。
总结：
不支持systemd-notify的服务不可以使用Type=notify启动类型，可以改用Type=simple或其他启动类型。
以下是网友整理的systemd-notify使用手册：
systemd-notify 中文手册 [金步国]
systemd.service 中文手册 [金步国]
名称
systemd-notify — 向 systemd 报告服务状态的变化
大纲
systemd-notify [OPTIONS...] [VARIABLE=VALUE...]
描述
systemd-notify 可用于 在守护进程脚本中向 systemd 报告进程状态的变化。 可用于发送任意信息， 其中最重要的是 报告"启动已完成"的消息。
此工具基本上就是对 sd_notify() 的简单包装， 以便于在脚本中使用。详见 sd_notify(3) 手册。
注意，在报告状态更新的同时， 还可以传递一系列环境变量。
注意，在默认情况下(也就是调用此命令的服务单元含有 NotifyAccess=none)， systemd 并不从此命令接受状态更新消息。
注意，服务单元的 sd_notify() 通知能够正常工作的前提， 是必须满足如下两个条件之一： (1)在 PID=1 的进程处理通知消息时，发送该通知的进程依然在运行； (2)发送该通知的进程是 systemd 派生的子进程(也就是匹配 NotifyAccess=main 或 NotifyAccess=exec 的进程)。 如果服务单元中的某个辅助进程在发送了 sd_notify() 通知之后就立即退出了， 那么 systemd 将有可能来不及将该通知关联到这个服务单元上。 在这种情况下，即使明确设置了 NotifyAccess=all ， 该通知也可能会被忽略掉。
systemd-notify 会首先尝试以调用进程的PID来调用 sd_notify() (此操作仅在确实拥有足够权限的情况下才会成功)， 如果失败，将会使用其自身的PID再次调用 sd_notify() 。 这种做法对于从 shell 脚本中调用 systemd-notify 命令非常有用， 特别是当服务的主进程是 shell 的时候(由于 NotifyAccess=all 的限制)， 因为在这种情况下， shell 进程(而不是 systemd-notify 进程)将成为消息的发送者。
选项
能够识别的命令行选项如下：
--ready
向 systemd 报告"启动已完成"的消息。 这等价于 systemd-notify READY=1 。 详见 sd_notify(3) 手册。
--pid=
向 systemd 报告主守护进程的 PID 。 如果 PID 参数被省略， 将使用调用 systemd-notify 的进程的 PID 。 这等价于 systemd-notify MAINPID=$PID 。 详见 sd_notify(3) 手册。
--uid=USER
向 systemd 报告此消息来自哪个用户，也就是使用指定的 USER 取代调用此命令的用户，作为此通知消息的发送者。 USER 既可以是一个UID数值也可以是一个用户名字符串。 此选项需要足够的权限才能操作进程的用户标识。
--status=
向 systemd 发送一个任意内容的字符串消息。 这等价于 systemd-notify STATUS=… 。 详见 sd_notify(3) 手册。
--booted
用于检查系统的 init 进程是否为 systemd ， 返回 0 表示系统的 init 进程是 systemd ，返回非零表示其他。 此选项并不发送任何消息，因此与其他选项没有任何关系。 详见 sd_booted(3) 手册。 另一种检查方法是 systemctl(1) 的 is-system-running 命令。 若返回 "offline" 则表示 系统的 init 进程不是 systemd
-h, --help
--version
退出状态
返回值为 0 表示成功， 非零返回值表示失败代码。
--end--