Самостоятельная регистрация: сценарий оболочки Busybox, который записывает стандартный вывод в файл

Question

Мой вопрос связан с ответом, опубликованным jbarlow на следующий вопрос: перенаправить КОПИЮ stdout в файл журнала из самого скрипта bash

Я использовал предложенный скрипт, как указано ниже. Я должен использовать это, потому что у меня нет доступа к полной версии bash (как указывает jbarlow), потому что я использую версию busybox для rootroot.

#!/bin/sh

if [ "$SELF_LOGGING" != "1" ]
then
    PIPE=tmp.fifo
    mkfifo $PIPE

    # Keep PID of this process
    SELF_LOGGING=1 sh $0 $* >$PIPE &
    PID=$!

    tee logfile <$PIPE &

    # Safe to rm pipe because the child processes have references to it
    rm $PIPE    
    wait $PID

    # Return same error code as original process
    exit $?
fi

Проблема, которую я нахожу, состоит в том, что кажется, что что-то может зависнуть от этого сценария. Например, строка замороженного скрипта с использованием приведенного выше кода выглядит следующим образом:

Process 29750 attached - interrupt to quit
open("/tmp/tmp.fifo", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
write(2, "/usr/bin/runStuff", 24) = 24
write(2, ": ", 2)                       = 2
write(2, "line ", 5)                    = 5
write(2, "45", 2)                       = 2
write(2, ": ", 2)                       = 2
write(2, "can't open ", 11)             = 11
write(2, "/tmp/tmp.fifo", 21)   = 21
write(2, ": ", 2)                       = 2
write(2, "no such file", 12)            = 12
write(2, "\n", 1)                       = 1
stat64("/sbin/tee", 0xbff7c20c)         = -1 ENOENT (No such file or directory)
stat64("/usr/sbin/tee", 0xbff7c20c)     = -1 ENOENT (No such file or directory)
stat64("/bin/tee", 0xbff7c20c)          = -1 ENOENT (No such file or directory)
stat64("/usr/bin/tee", {st_mode=S_IFREG|0755, st_size=18956, ...}) = 0
_exit(1)                                = ?
Process 29750 detached

То, на что это похоже (для меня, с ограниченным знанием в этом), - то, что тройник заканчивается, и родительский подлинник не умирает. Это верно? Если так, разве не отсутствие читаемого файла может привести к завершению сценария? тройник задний план, так что очевидно, что не имеет никакого контроля над родителем.

В качестве фона есть еще один процесс, который несколько раз вызывает его, если он умирает. Таким образом, возможно, что использование одного и того же файла вызывает ситуацию блокировки. Или, может быть, рм происходит до создания fifo?

Я подумал об использовании "read" с таймаутом, но могут быть ситуации, когда ничего не регистрируется часами.

Можно ли изменить сценарий, чтобы он не блокировался, и сценарий умрет, если / когда один из концов fifo умрет?