useradd: UID 0 не уникален

Why does the server process have to open FIFO again, it just has to read again after a client process has written into it, right?

Интересно, попробуем ваше предложение. Следующие результаты были получены на ядре Linux 4.9.0 -6 -amd64 (Ubuntu Linux ).

$ mkfifo t
$ (cat; cat) < t &    # run a "server" as a background job
[1] 4856
$ echo 1 > t
1
[1]+  Done                    ( cat; cat ) < t

Это не сработало, как мы хотели. Первый catчитает EOF, как и ожидалось, а затем завершает работу. Проблема в том, что второйcatтакже сразу считывает EOF, и поэтому наш «сервер» завершает работу. Невозможно ждать нового клиента (без многократного вызова чтения ()и траты процессорного времени ).

Если вы знаете, как манипулировать файловыми дескрипторами (FD )в оболочке, мы можем посмотреть на это другим способом, чтобы подтвердить это.

$ echo 1 > t &
$ exec 3 < t    # open "t" for reading, as FD 3.
$ cat <&3
1
[1]+  Done                    echo 1 > t
$ cat <&3
$

$ echo 2 > t &
[1] 5102
$ cat <&3
2
[1]+  Done                    echo 2 > t
$ cat <&3
$ 

Ответ заключается в том, что-open()-использование fifo позволяет блокировать доступ к нему для записи кем-то другим. Без этого шага все последующие вызовы read()из fifo немедленно вернут 0 (EOF ).

Когда я это заметил, мне стало интересно, как systemd-initctlработает. Эта программа эмулирует старый /dev/initctlfifo под systemd. (Отказ от ответственности :это не очень легко проверить; Я не буду документировать, как ). Ответ заключается в том, что systemd -initctl открывает fifo как для чтения, так и для записи. (Технически именно systemd открывает fifo, как указано в systemd -initctl.socket, и передает его в systemd -initctl ). Открытие fifo для одновременного чтения и записи — это особенность Linux -. Но, делая это, systemd реализует тот же трюк, о котором упоминает Стивенс далее :

To avoid this, a use­ful technique is for the daemon to open the FIFO two times- once for reading and once for writing. The file descriptor returned for reading is used to read the client requests , and the file descriptor for writing is never used. By having the FIFO always open for writing (as long as the daemon process exists) the reads do not return an EOF, but wait for the next client request.