hen*_*nje 6 upstart debian-wheezy sysvinit
我将我的服务器更新为 Debian wheezy 并尝试使用它。过了一会儿我想重新启动并遇到错误
shutdown: /run/initctl: No such file or directory
我在网上搜索，发现 initctl 来自 upstart。即使它没有根据 aptitude 安装并且servicesysvinit的命令仍然有效。我很感激任何帮助。
我在网上搜索，发现 initctl 来自 upstart。
这个错误是你从搜索引擎的研究中得到的，而不是手册页。
这个名字实际上是/run/initctl。新贵有一个/sbin/initctl. 两者是完全不同的东西。前者是一个 FIFO，用于向进程 #1 发送控制命令。后者是程序文件。
最初，（Linux 的）System Vinit会在启动时在进程 #1 中创建一个名为 的 FIFO /dev/initctl。诸如telinit通过打开该 FIFO 并向其写入消息来操作的程序，该进程 #1 将读取并对其执行操作。
诸如 Upstart、Joachim Nilssonfinit和 systemd 之类的系统提供了兼容性垫片，可在 中创建 FIFO /dev/initctl、侦听消息并将来自 System V 概念的命令转换为 finit/Upstart/systemd 等效项。因此，期望 System Vinit程序运行的工具仍然可以打开该 FIFO 并向其写入命令。（不过，并不是所有的 init 系统都提供这样的垫片。如果你问 Debian System V 的init人，他们会告诉你，这是一个文档很差的内部 API，不属于 System V 包的程序不应该真的是首先使用。）
然后，几年前，Debian的系统Vinit人决定FIFO打算从移动/dev/initctl到/run/initctl。因此，他们更改了它们init以在那里创建它，并更改了所有随附的工具init（例如shutdown、halt、telinit等）以在那里寻找它。
不过，他们只告诉了其他系统之一的开发人员。因此，当非 System Vinit系统管理系统时，它们仍然主要在/dev/initctl. 如果将 System Vinit工具与此类非 System Vinit系统混合使用，则该工具将尝试在其新位置打开 FIFO，同时系统在旧位置提供它。
现在，解决方法应该是显而易见的：快速符号链接可以解决问题。
ln -s /dev/initctl /run/initctl它一直持续到下一次重新启动（当可能已经将系统重新启动到一个不会混淆初始化系统的更明智的配置时，这将尝试使 FIFO 本身）。Debian System V
init软件包的维护者之一 Roger Leigh在 2012 年指出了这一点。
请注意，根本没有必要使用 System Vinit工具。许多 init 系统上缺乏兼容性垫片 FIFO 并不是什么大问题。systemd，暴发户，NOSH等系统都倾向于提供自己的工具，如版本halt，reboot，telinit，等等，反正。这些工具使用各自系统的本地协议，根本不使用initctlFIFO。systemd 的 shims 与相关的 D-Bus 协议直接对话以处理 #1。Upstart 的 shims 直接生成相关的 upstart 事件。nosh 的垫片直接将相关信号发送到进程#1。
所有在另一个答案中摸索的东西和评论归结为两点：
/bin/bash进程#1启动，而不是一些实际的初始化系统，那么当然不会有initctl任何地方的FIFO。如前所述，它是创建它的初始化系统。重新。在每次引导时。mkfifo并不会神奇地使应该在 FIFO 读取端侦听消息的服务器存在。这就是为什么实用程序随后尝试将消息向下发送到 FIFO 不起作用的原因。您如何设法使 Debian 7 进入一种使用 System Vinit工具但当时正在运行另一个 init 系统的状态是另一回事。很有可能做到这一点，尤其是当一个人正在切换init 系统时。对于 Debian 7 来说，这真的没有解决，而且系统可能会进入一些奇怪的状态。甚至在 Debian 8 中（目前的情况）也并非一帆风顺。幸运的是，这不是你的问题。☺
initctl(8) . Ubuntu 手册页。/dev/initctl到/run。638019. Debian 错误跟踪系统。debian/patches/93_run_initctl.patch. alioth.debian.org。halt, poweroff,reboot . systemd 手册页。freedesktop.org。reboot(8), halt(8), poweroff(8)。Ubuntu 手册页。我在 qemu 上的 RPi 模拟器上运行的 raspbian wheezy遇到了完全相同的问题的问题。我似乎已经解决了我的特定设置的问题。它是否适合你是另一回事。我希望如此。老实说，我不确定问题是什么，或者它如何自行解决，但我已经记录了我所做的一切，并且没有遗漏任何步骤。
\n\n我使用qemu设置了一个模拟的 Raspberry Pi ，使用这两个指南1：
\n\n\n\n首次使用命令启动时qemu（注意使用init=/bin/bash）
qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw init=/bin/bash" -hda 2013-09-25-wheezy-raspbian.img
一旦系统启动，我发现，就像OP一样，halt命令不会运行，而是给出错误：
init: /run/initctl: No such file or directory\n然后我跑了（感谢我得到了一个错误标志“init：/ dev / initctl：没有这样的文件”）
\n\nmkfifo /run/initctl\n这阻止了No such file or directory错误，但仍然没有关闭系统，而是给出了错误
init: timeout opening/writing control channel /run/initctl. \n我将/run/initctl刚刚创建的与我正在工作的 RPi 上的进行了比较，使用ls -l /run/initctl它们看起来完全相同：
prw------- 1 root root 0 Jan 1 1970 /run/initctl\n不管怎样，我继续按照指南的步骤进行，经过一段时间后reboot -f。现在我相信下一步就是修复发生的地方。我使用“正常”启动启动了 qemu RPi，省略了init=/bin/bash
qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda 2013-09-25-wheezy-raspbian.img
Wheezy 启动进入raspi-config. 我只是更改了 pi 用户的密码和主机名，然后点击并重新启动系统。然后我再次启动 qemu RPi
qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda 2013-09-25-wheezy-raspbian.img
它启动进入 tty 登录屏幕。我登录了，跑了startx。开始后X我就跑了sudo shutdown -h now。它按预期关闭并停止，没有任何init:错误。
在没有启动的情况下启动（虚拟）设备init=/bin/bash似乎可以解决该问题。我不确定这是否相当于应该解决问题2的硬启动，或者是否是和 的组合。我知道这不是我最好的答案，但希望它会有所帮助。mkfiforeboot
1有太多的信息无法尝试总结，以防链接死亡。然而，该设置很大程度上与OP的问题无关。
\n\n2根据can\t restart debian and systemd-sysv, sysvinit: issues restarting when Switching between systemd-sysv and sysvinit
\n| 归档时间： |
|
| 查看次数： |
13917 次 |
| 最近记录： |