运行 init 脚本在后台启动守护进程以减少启动时间？

Question

我正在寻找加快单核嵌入式 Linux 系统启动时间的方法。某些自定义守护程序启动期间会出现明显的延迟。一旦它们启动，它们就会在后台运行，但让它们运行的​​过程需要很长时间。

##This takes long during startup
##In file /etc/init.d/run_custom_daemon
...
/opt/bin/custom_daemon -d
...

如果我将守护进程的启动放在后台，我会发现启动时间会减少。

##This takes much less but is it a real gain?
##In file /etc/init.d/run_custom_daemon
...
/opt/bin/custom_daemon -d &
...

从只关注进入登录屏幕需要多长时间的人来说，这似乎是一种加速。但是，我觉得这可能只是表面上的改进，如果启动序列中的下一个进程期望守护进程在启动时运行，则可能会导致问题。

这是一个正确的假设吗？

Answer 1

通常守护进程会进行两次或三次分叉，然后父进程退出。当守护进程在 bg 中启动时，非交互式 shell 不会等待第一个 fork 退出。因为它没有什么可做的，所以它会立即退出。这可能会加快一点。如果您确定守护进程不会失败，我认为这不会产生任何不良后果。

为了消除 fork 并因此加速，它可能是 'exec'd like exec daemon。但是'bg'和'exec'无法获取守护进程的返回值。

当“init”或由 init 生成的某些代理通过某种 shell 魔法弄清楚时，下一个要运行的 init 脚本并克隆自身以执行“下一个 init scritp”，并且 exec[lv]* 系列函数已找到# ！并以“下一个初始化脚本”作为参数运行解释器，解释器已解析并执行“下一个初始化脚本”，直到启动下一个守护进程，内核间歇性地获取 CPU 时间...，第一个守护进程有望启动。

某个守护进程的第一个 fork 除了检查第二个“fork”系统调用的退出并退出之外没有任何作用。其他人可能会在第一个分叉中关闭打开的“fd”并在 0,1 和 2 上打开 /dev/null，而不是推迟。一些基准测试可能会揭示性能。