嗨，这个问题我刚好在日常运维中处理过好几次，给你几个靠谱的方案，完全不用依赖cron重启后执行命令：

首先得明确：systemd的mask操作本身就是持久化的——你手动执行systemctl mask <你的服务名>后，即使重启系统，服务依然会保持masked状态，除非有人手动执行unmask，或者第三方RPM的安装脚本主动做了unmask操作。但如果你想通过配置文件的方式（比如集成到你的部署配置里，不用手动敲命令）来实现，有两种标准做法：

方法一：用符号链接实现彻底屏蔽（最接近原生mask效果） #

systemd读取服务配置时，会优先加载/etc/systemd/system/下的文件，而不是RPM包默认安装的/usr/lib/systemd/system/路径。所以你只需要在/etc/systemd/system/下创建一个指向/dev/null的符号链接，命名和目标服务完全一致：

ln -s /dev/null /etc/systemd/system/<你的服务名>.service

这个链接会直接覆盖原始的服务配置，让systemd认为这个服务不存在，从而达到和systemctl mask完全一样的效果。只要这个链接存在，哪怕第三方RPM更新了原始服务文件，屏蔽状态也不会被打破。你可以把这个链接的创建步骤加到你的部署脚本里，或者打包进自己的配置RPM中，实现自动化部署。

方法二：用override配置文件限制服务启动（非严格屏蔽，但更灵活） #

如果你不想彻底“隐藏”服务，只是确保它永远无法启动，可以用systemd的override配置。先创建配置目录：

mkdir -p /etc/systemd/system/<你的服务名>.service.d

然后在这个目录下创建override.conf，内容如下：

[Unit]
# 设置一个永远不满足的条件，让服务无法启动
ConditionPathExists=/does/not/exist

这样一来，无论这个服务是否被enable，启动时都会因为条件不满足而失败。这种方式的好处是，你可以随时修改条件来临时恢复服务，而不用删除符号链接；缺点是它不是严格意义上的mask——用户依然可以手动执行systemctl start，只是会启动失败。

另外补充一点：如果第三方RPM的安装脚本里包含了systemctl unmask或者强制enable的操作，那你需要在RPM安装完成后，重新执行上述的屏蔽操作（比如在你的部署脚本里加一步检查），确保屏蔽状态生效。

备注：内容来源于stack exchange，提问作者m.divya.mohan