我找不到在 systemd 中执行某些本地脚本(或非常本地的命令)的正确方法,我已经知道我不能为此类脚本创建服务(在 systemd 中的一个单元中)(或者我必须?)...
我发现的解决方法是创建 rc.local 并赋予它执行权限。
printf '#!/bin/bash \n\nexit 0' >/etc/rc.local
chmod +x /etc/rc.local
Run Code Online (Sandbox Code Playgroud)
例如,如果我得到一个由你配置的简单 rc.local 的旧服务器,我会知道你做了什么以及在发行版上升级或安装新东西会有多大伤害,因为 rc.local 受到外部尊重包,但另一方面,如果我安装一个服务器并创建一个或两个或三个 systemd 单元(甚至 sysvinit 服务),只是为了完成一个简单的任务,这有时会使您的生活变得更艰难,而我的单元远不止于此名称可能有一天会与发行版开发创建的新服务的名称发生冲突,并且可能在升级时安装,从而导致我的脚本出现问题!
我看到另外一个问题问哪里是rc.local中,答案是创造它,并给执行权限,我想我的问题是真的不是一个重复的,因为我不想知道它在哪里-相信我,我只是想要接受它过时,但我不能找到做这种事情的正确方法,我应该真正创造一个单元,只是这样一些简单的?
sou*_*edi 29
正如其他地方所指出的,rc-local.service在systemd.
poweroff/reboot命令)。rc-local.service一种方式,但 Debian 提供了一个插入文件,它至少可以更改一项重要设置。rc-local.service通常可以很好地工作。如果您担心上述问题,您需要做的就是制作自己的副本!这是魔法:
# /etc/systemd/system/my-startup.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/libexec/my-startup-script
[Install]
WantedBy=multi-user.target
Run Code Online (Sandbox Code Playgroud)
我认为您不需要了解每一个细节[*],但这里有两件事您需要了解。
您需要使用systemctl enable my-startup.service.
如果您的脚本依赖于任何其他服务,包括network-online.target,您必须声明它。例如,添加一个[Unit]部分,其中包含行Wants=network-online.target和After=network-online.target。
您无需担心对“早期启动”服务的依赖——特别是之前已经订购的服务basic.target。服务喜欢my-startup.service是自动排序后basic.target,除非他们设置DefaultDependencies=no。
如果您不确定您的依赖项之一是否是“早期启动”服务,一种方法是basic.target通过运行systemctl list-dependencies --after basic.target. (请注意,是--after,不是--before)。
我认为有一些考虑也适用于 pre-systemd rc.local:
rc.local.[*] 我使用Type=oneshot+RemainAfterExit=yes是因为它对大多数一次性脚本更有意义。它正式表明您将运行一系列命令,my-startup一旦完成,这些命令将显示为“活动”,并且您将不会启动守护程序。
Jde*_*eBP 16
rc.local。正如我所说的 CentOS 7、Debian 8和Ubuntu 15:
您使用的是 systemd+Linux 操作系统。 /etc/rc.local是 systemd 中的双重向后兼容机制,因为它是一种向后兼容机制,它本身就是 van Smoorenburg System 5rc克隆中的兼容机制。
使用/etc/rc.local可能会出错。人们对 systemd 的运行rc.local方式和引导程序中完全相同的位置并不像他们习惯的那样以完全相同的方式运行这一事实感到惊讶。(或者错误地期望:事实上,它并没有在旧系统中最后运行,正如 OpenBSD 手册仍然指出的那样。)其他人惊讶于他们在rc.local期待旧的做事方式时所建立的事实,是然后完全被新的喜欢撤消udev规则,NetworkManager的,systemd-logind,systemd-resolved,或各种“套装” S。
正如“为什么在 Arch 安装时`init 0` 会导致“Excess Arguments”?所举例说明,一些操作系统已经提供了没有向后兼容功能的systemd ,例如systemd-rc-local-generator生成器。 虽然 Debian 仍然保留向后兼容功能,但Arch Linux 构建 systemd 时关闭了它们。所以在 Arch 和类似的操作系统上,它期望/etc/rc.local 被完全忽略。
忘记了rc.local。这不是要走的路。你有一个 systemd+Linux 操作系统。所以制作一个合适的 systemd 服务单元,不要从两个级别的向后兼容性开始。(在Ubuntu和Fedora,它是3次来除去,面包车Smoorenburg系统5rc克隆随后rc.local已经被随后本身两次通过暴发户,然后由systemd取代,在十年前,第一次。)
还要记住迁移到 systemd 的第一条规则。
这甚至不是 systemd 特有的新想法。在 van Smoorenburgrc和 Upstart 系统上,要做的是制作适当的 van Smoorenburgrc脚本或 Upstart 作业文件,而不是使用rc.local. 甚至 FreeBSD 的手册也指出,现在人们创建了一个合适的 Mewburnrc脚本而不是使用/etc/rc.local. Mewburnrc是在 2000 年由 NetBSD 1.5 引入的。
/etc/rc.local日期从 Unix 第七版及之前的时间开始。它在 1983 年被AT&T Unix System 3(与AT&T Unix System 5略有不同)中/etc/inittab的基于运行级别取代。即使那现在已经成为历史。rc/etc/inittab
为您的服务管理系统创建适当的本机服务定义,无论是 nosh 工具集的服务包service-manager和system-control,/etc/rc.d/Mewburn的脚本rc,systemd 的服务单元文件,Upstart 的作业文件,runit/s6/daemontools 的服务目录-encore,甚至是/etc/init.d/van Smoorenburg 的脚本rc。
在 systemd 中,这种管理员添加的服务单元文件/etc/systemd/system/通常(或/usr/local/lib/systemd/system/很少)进入。使用 nosh 服务管理器,/var/local/sv/是本地服务包的常规位置。rcFreeBSD 上的Mewburn使用/usr/local/etc/rc.d/. 不过,打包的服务单元文件和服务包(如果您正在制作它们)放在不同的地方。
rc.local. FreeBSD 系统管理员手册。2016-04-23。/etc/rc.local或chmod -x它。红帽错误 #734268。rc.local是起步早。systemd 错误 #7703rc.local. bencane.com。/etc/inittab已成为过去。. 经常给出答案。systemd.unit”。systemd doco 的勘误表。经常给出答案。https://www.linuxbabe.com/linux-server/how-to-enable-etcrc-local-with-systemd的摘要
创建/etc/systemd/system/rc-local.service:
# /etc/systemd/system/rc-local.service
[Unit]
Description=/etc/rc.local Compatibility
ConditionPathExists=/etc/rc.local
[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99
[Install]
WantedBy=multi-user.target
Run Code Online (Sandbox Code Playgroud)
然后:
sudo touch /etc/rc.local
sudo chmod +x /etc/rc.local
sudo systemctl enable rc-local
Run Code Online (Sandbox Code Playgroud)
检查:
sudo systemctl start rc-local.service
sudo systemctl status rc-local.service
Run Code Online (Sandbox Code Playgroud)
| 归档时间: |
|
| 查看次数: |
46040 次 |
| 最近记录: |