старый драйвер nvidia из apt install и новый из файла .run

stdin - дескриптор файла 0 . Закрытие файлового дескриптора процесса - это то, что может быть выполнено активно только самим процессом. stdin закрывается, когда процесс решает закрыть его.

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

Такие приложения, как cat , cut , wc ..., которые читают со своего стандартного ввода, обычно завершаются, когда это происходит, потому что их роль заключается в обработке их ввода. до конца, пока не закончится ввод.

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

В:

echo foo | cat

Как только echo записал "foo \ n" , он завершается, что приводит к закрытию записывающего конца канала, затем читает () , выполненное cat на другом конце, возвращает 0 байтов, что говорит cat , что читать больше нечего, а затем cat решает выйти.

В

echo foo | sleep 1

сон завершается только по истечении 1 секунды. Его стандартный ввод, превращающийся в закрытый канал, не имеет к этому никакого отношения, сон даже не читает из своего стандартного ввода.

По-другому обстоит дело с пишущим концом каналов (или сокетов, если на то пошло).

Когда все fds на считывающей стороне закрыты, любая попытка записи на fds, открытых для записывающей стороны, вызывает отправку SIGPIPE процессу, вызывая его смерть (если только он не игнорирует сигнал, в этом случае write () не работает с EPIPE ).

Но это происходит только тогда, когда они пытаются писать.

Например, в:

sleep 1 | true

Несмотря на то, что true сразу завершается, а конец чтения сразу же закрывается, sleep не уничтожается, потому что он не пытается напишите в его stdout.

Теперь о / proc / fd / pid / n , отображаемом красным в выводе ls -l --color (как упоминалось в первой версии вашего вопрос ), это только потому, что ls выполняет lstat () в результате readlink () для этой символической ссылки, чтобы попытаться определить тип цель ссылки.

Для файловых дескрипторов, открытых в каналах, или сокетах, или файлах в других пространствах имен, или удаленных файлах, результат readlink не будет фактическим путем в файловой системе, поэтому второй lstat () сделанный ls завершится ошибкой, и ls сочтет это неработающей символической ссылкой, а неработающие символические ссылки отображаются красным цветом. Вы получите это с любым fd на любом конце любого канала, независимо от того, закрыт ли другой конец канала или нет. Попробуйте использовать ls --color = always -l / proc / self / fd | cat , например.

Чтобы определить, указывает ли fd на сломанный канал, в Linux вы можете попробовать lsof с параметром -E .

$ exec 3> >(:) 4> >(sleep 999)
$ lsof -ad3-4 -Ep "$$"
COMMAND   PID     USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
zsh     13155 stephane    3w  FIFO   0,10      0t0 5322414 pipe
zsh     13155 stephane    4w  FIFO   0,10      0t0 5323312 pipe 392,sleep,0r

Для fd 3 lsof не смог найти какой-либо другой процесс на считывающем конце канала. Однако будьте осторожны, вы можете получить такой вывод:

$ exec 5<&3
$ lsof -ad3-5 -Ep "$$"
COMMAND   PID     USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
zsh     13155 stephane    3w  FIFO   0,10      0t0 5322414 pipe 13155,zsh,5w
zsh     13155 stephane    4w  FIFO   0,10      0t0 5323312 pipe 392,sleep,0r
zsh     13155 stephane    5w  FIFO   0,10      0t0 5322414 pipe 392,sleep,3w 13155,zsh,3w

fds 3 и 5 по-прежнему относятся к сломанным каналам, потому что нет fd в конце чтения (похоже, в lsof есть ошибка, поскольку тот факт, что sleep тоже имеет свой fd 3 открытый, чтобы сломанная труба отражалась не везде).

Чтобы убить процесс, как только канал, открытый на его стандартном вводе, теряет свою последнюю запись (становится сломанной), вы можете сделать что-то вроде:

run_under_watch() {
  perl -MIO::Poll -e '
     if ($pid = fork) {
       $SIG{CHLD} = sub {
         wait;
         exit($? & 127 ? ($? & 127) + 128 : $? >> 8);
       };
       $p = IO::Poll->new; $p->mask(STDIN, POLLERR); $p->poll;
       kill "TERM", $pid;
       sleep 1;
       kill "KILL", $pid;
       exit(1);
     } else {
       exec @ARGV
     }' "$@"
 }

Что будет отслеживать состояние ошибки на стандартном вводе (и в Linux, кажется произойдет, как только не останется писателя, даже если в канале остались данные) и убейте дочернюю команду, как только это произойдет. Например:

 sleep 1 | run_under_watch sleep 2

Завершит процесс сна 2 через 1 секунду.

В общем, это немного глупо. Это означает, что вы потенциально убиваете команду до того, как она успела обработать конец ввода. Например, в:

 echo test | run_under_watch cat

Вы обнаружите, что cat иногда убивают до того, как успевает вывести (или даже прочитать!) "test \ n" . Этого не избежать, наш наблюдатель не может знать, сколько времени нужно команде для обработки ввода. Все, что мы можем сделать, это задать период отсрочки перед уничтожением "TERM" , надеясь, что этого достаточно для команды, чтобы прочитать содержимое, оставшееся в конвейере, и сделать с ним то, что нужно.