在引导过程的哪一点可以使用管道？

Question

我有一个使用Linux的RTAI扩展构建的系统。它有一个进程在启动时作为根进程运行。它创建了一些命名管道和chmod 777。管道属于root用户，并且拥有prwxrwxrwx权限，但是没有一个用户进程可以对它们进行写入或读取。这些管子(用C语言)是这样做的

unlink(pipename);
mkfifo(pipename, 0777);
chmod(pipename, 0777);

如果我以用户身份登录，su到root，终止进程并重新启动它，退出root，命名管道仍然属于root，并且拥有prwxrwxrwx的权限，但这一次，用户进程可以从它们读取和写入。

问:如果程序作为引导过程的一部分运行，我还需要做什么才能访问命名管道。

此外，我如何确保这是在所有通信机制建立之后执行的最后一个进程。

编辑

我已经更改了标题(旧的标题是为引导进程设置管道权限)

通过将流程转换为rc.local，我终于使它发挥了作用。由于编码器使用的是RTAI，他认为这个过程必须与所有其他RTAI进程同时启动。其他进程没有使用任何Unix通信机制，所以这并不重要。当他开始使用管道时，它必须移到多用户级别的末尾。

这是我找不到解释的部分:在引导过程的什么时候使用管道是可以的？我已经把它移到最后了，但它可能会更早。

Answer 1

终于找到了问题的根源。

1. 我加了一个延迟，没什么区别。
2. 然后我发现，即使我拥有666的mkfifo，权限仍然是644。由于FIFO属于root，所以没有其他进程可以写入它。因此，我在mkfifo之后添加了一个chmod。这使得FIFO可以写。
3. 写作问题是固定的，但作者仍然没有从公开中回来。
4. 这是SuSE特有的问题。这个过程是在boot.local中开始的，太早了。在其他系统上，它可以在rc.local中启动，但是在SuSE上，它必须在after.local上启动。将程序移动到after.local，一切都神奇地开始工作了。

简而言之，解决办法是

1. 创建FIFO后的chmod
2. 将可执行文件移动到after.local on SuSE

我的问题的答案是把它放在rc.local为Ubuntu，Centos和Debian，after.local为SuSE。