[Comm] man через ssh

[Dmitry Chistikov]

Добрый день!

Начну с конца:

> Если попробовать запустить в SSH-консоли
> sh -c "(cd /usr/share/man && man-source 
> '/usr/share/man/man1/strace.1.bz2' '153' '1100i' | /usr/bin/nroff -S -p 
> -t -Dkoi8-r -mtty -mandoc | /usr/bin/less -isR)"
> то ошибок нет

Если Вы перечитаете вывод man -d strace, то обратите внимание на то, что
сам последний sh -c "..." и не запускается: сообщения об ошибках выводятся
раньше, например при определении preprocessor sequence:

> [...]
> bzip2: I/O or other error, bailing out.  Possible reason follows.
> bzip2: Broken pipe
> 	Input file = /usr/share/man/man1/strace.1.bz2, output file = (stdout)
> using default preprocessor sequence
> man:
> not executing command:
> [...]

В этих местах man делает
popen("/bin/bzip2 -c -d /usr/share/man/man1/strace.1.bz2", "r"),
таким образом форкаясь и заменяя (execve()) дочерний процесс на
sh -c "/bin/bzip2 -c -d /usr/share/man/man1/strace.1.bz2",
который после этого делает еще один execve на собственно
/bin/bzip2 -c -d /usr/share/man/man1/strace.1.bz2

Этот bzip2 начинает разжимать руководство и выводить его крупными кусками
в канал. Родительский процесс (сам man) читает из этого канала, причем
на данный момент ему достаточно первого куска, после чего он делает
pclose(). Если bzip2 еще не сделал всех своих write(), то на очередном
вызове он получает SIGPIPE и умирает.

У меня это происходит примерно так (заменил man -d на man -w, механика
вроде не меняется):

[pid 23192] write(1, ".\\\" Copyright (c"..., 4096) = 4096
[pid 23191] <... read resumed> ".\\\" Copyright (c"..., 4096) = 4096
[pid 23191] waitpid(23192, Process 23191 suspended
 <unfinished ...>
[pid 23192] read(4, "", 4096)           = 0
[pid 23192] write(1, ".  When the call"..., 4096) = -1 EPIPE (Broken pipe)
[pid 23192] --- SIGPIPE (Broken pipe) @ 0 (0) ---
Process 23191 resumed
Process 23192 detached
<... waitpid resumed> [{WIFSIGNALED(s) && WTERMSIG(s) == SIGPIPE}], 0) = 23192
--- SIGCHLD (Child exited) @ 0 (0) ---

Таким образом, у меня bzip2 перед смертью не успевает ничего сказать.
В Вашем примере, судя по всему, SIGPIPE не приводит к смерти bzip2,
поэтому тот, зафиксировав i/o error (для него это критично), сообщает
о пришедшем сигнале и завершается.

Я делаю вывод, что в какой-то момент на SIGPIPE ставится обработчик.
Попробуйте отследить, когда это происходит:

$ ssh localhost -- strace -f -e trace=signal,process -- man -w strace

Правильно ли я понимаю, что если не заворачивать все это дело в ssh,
то bzip2 молчит?

-- 
Дмитрий Чистиков