Search code examples
linuxnamed-pipesbootrtai

At what point of the boot process is it ok to use pipes

I have a system built using the RTAI extension to Linux. It has a process that runs as root on startup. It creates some named pipes and chmod 777 them. The pipes are owned by root and have the permissions prwxrwxrwx but none of the user processes can write to or read from them. The pipes are made (in C) like this

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

If I login as the user, su to root, kill the process and restart it, come out of root, the named pipes are still owned by root and have the permissions prwxrwxrwx but this time, the user processes can read and write from them.

Question: what else do I need to do so that the named pipes are accessible if the program is run as part of the boot process.

Also, how do I make sure that it is the very last process that is executed after all the comms mechanisms have been set up.

Edit

I've changed the title (old one was Setting pipe permissions for boot process)

I have finally got it working by shifting the process into rc.local. Since the coder was using RTAI, he thought that the process had to be started at the same time as all the other RTAI processes. The other processes didn't use any of the Unix comms mechanisms so it didn't matter. When he started using pipes, it had to be shifted to the end of the multiuser level.

This is the part I cannot find an explanation for: at what point in the boot process would it be OK to use pipes? I have shifted it to the end but it could be earlier.

Solution

  • Finally got to the bottom of the problem.

    1. I added a delay and it made no difference.
    2. Then I found that even though I mkfifo with 666, the permissions were still 644. Since the FIFO was owned by root, no other process could write to it. As a result, I added a chmod after the mkfifo. That made the FIFO writable.
    3. The writing problem was fixed but the writer still didn't return from the open.
    4. This was a SuSE specific problem. The process was started in boot.local, which was way too early. On other systems, it can be started in rc.local but on SuSE, it had to be started on after.local. Moved the program to after.local and everything magically started working.

    In short, the fix was

    1. chmod after creating the FIFO
    2. Move the executable to after.local on SuSE

    The answer to my question is put it in rc.local for Ubuntu, Centos and Debian, after.local for SuSE.