[Comm] man через ssh

[Comm] man через ssh

[Alexey Bochenin]

Подскажите, пожалуйста, чем могут быть вызваны сообщения в SSH-консоли 
типа ниже приведенных?

$ ssh localhost man strace|head

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)

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)
STRACE(1)                                          STRACE(1)
NAME
        strace - trace system calls and signals

Мануал при этом показывается на экране, так что ошибка вроде не 
критичная. Что любопытно, возникает она лишь при просмотре больших 
руководств, типа man bash, man ls, и др. А при просмотре небольших манов 
объемом около 100 строк (man df) - в консоли нет ошибок.


Система - x86_64, Сизиф примерно на начало февраля.
$ rpm -q man
man-1.6f-alt11

$ man -d strace
Reading config file /etc/man.conf
found man directory /usr/share/man
found man directory /usr/X11R6/man
found man directory /usr/local/man
found man directory /usr/local/share/man
found manpath map /bin --> /usr/share/man
found manpath map /sbin --> /usr/share/man
found manpath map /usr/bin --> /usr/share/man
found manpath map /usr/sbin --> /usr/share/man
found manpath map /usr/local/bin --> /usr/local/share/man
found manpath map /usr/local/sbin --> /usr/local/share/man
found manpath map /usr/X11R6/bin --> /usr/X11R6/man
found manpath map /usr/bin/X11 --> /usr/X11R6/man
found manpath map /usr/bin/mh --> /usr/share/man

using /usr/bin/less -isR as pager

using /usr/bin/less -isR as browser

using /bin/cat to dump HTML pages as text

path directory /home/bochenin/bin is not in the config file
and we found no man directory nearby

path directory /bin is in the config file
adding /usr/share/man/ru to manpath
adding /usr/share/man to manpath

path directory /usr/bin is in the config file

path directory /usr/local/bin is in the config file
adding /usr/local/share/man to manpath

path directory /usr/X11R6/bin is in the config file
adding /usr/X11R6/man to manpath

path directory /usr/games is not in the config file
and we found no man directory nearby

adding mandatory man directories

adding /usr/local/man to manpath

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)
no cat page stored because of nonstandard line length

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:
   (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)


Если попробовать запустить в 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)"
то ошибок нет

-- 
WBR, Alexey

Re: [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 молчит?

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

Re: [Comm] man через ssh

[Alexey Bochenin]

24.02.2011 12:28, 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) ---

Вот какое поведение наблюдаю у себя
$ ssh localhost -- strace -f -e trace=all -- man -w strace
...
[pid 27496] write(1, ".\\\" Copyright (c) 1991, 1992 Pau"..., 4096) = 4096
[pid 27495] <... read resumed> ".\\\" Copyright (c) 1991, 1992 Pau"..., 
4096) = 4096
[pid 27495] close(4)                    = 0
[pid 27495] wait4(27496, Process 27495 suspended
  <unfinished ...>
[pid 27496] read(4, "", 4096)           = 0
[pid 27496] write(1, " unfinished .\nWhen the call retu"..., 4096) = -32
[pid 27496] write(2, "\nbzip2: I/O or other error, bail"..., 67
bzip2: I/O or other error, bailing out.  Possible reason follows.
) = 67
[pid 27496] write(2, "bzip2: Broken pipe\n", 19bzip2: Broken pipe
) = 19
[pid 27496] write(2, "\tInput file = /usr/share/man/man"..., 71	Input 
file = /usr/share/man/man1/strace.1.bz2, output file = (stdout)
) = 71
[pid 27496] exit_group(1)               = ?
Process 27495 resumed
Process 27496 detached

>
> Таким образом, у меня bzip2 перед смертью не успевает ничего сказать.
> В Вашем примере, судя по всему, SIGPIPE не приводит к смерти bzip2,
> поэтому тот, зафиксировав i/o error (для него это критично), сообщает
> о пришедшем сигнале и завершается.
>
> Я делаю вывод, что в какой-то момент на SIGPIPE ставится обработчик.
> Попробуйте отследить, когда это происходит:
>
> $ ssh localhost -- strace -f -e trace=signal,process -- man -w strace
>
> Правильно ли я понимаю, что если не заворачивать все это дело в ssh,
> то bzip2 молчит?
>

Да, если не заворачивать все это дело в ssh, то bzip2 молчит. Ниже 
приведен strace по сигналам, но я не вижу SIGPIPE в листинге

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

execve("/usr/bin/man", ["man", "-w", "strace"], [/* 15 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x7f3944605700) = 0
clone(Process 24150 attached
child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7f39446059d0) = 24150
[pid 24150] execve("/bin/sh", ["sh", "-c", "/bin/bzip2 -c -d 
/usr/share/man/"...], [/* 15 vars */]) = 0
[pid 24150] arch_prctl(ARCH_SET_FS, 0x7fa8bc650700) = 0
[pid 24150] rt_sigprocmask(SIG_BLOCK, NULL, [PIPE], 8) = 0
[pid 24150] rt_sigprocmask(SIG_BLOCK, NULL, [PIPE], 8) = 0
[pid 24150] rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 
0x7fa8bbf25750}, {SIG_DFL, [], 0}, 8) = 0
[pid 24150] rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 
0x7fa8bbf25750}, {SIG_DFL, [], SA_RESTORER, 0x7fa8bbf25750}, 8) = 0
[pid 24150] rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 
0x7fa8bbf25750}, {SIG_DFL, [], 0}, 8) = 0
[pid 24150] rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 
0x7fa8bbf25750}, {SIG_DFL, [], SA_RESTORER, 0x7fa8bbf25750}, 8) = 0
[pid 24150] rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 
0x7fa8bbf25750}, {SIG_DFL, [], 0}, 8) = 0
[pid 24150] rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 
0x7fa8bbf25750}, {SIG_DFL, [], SA_RESTORER, 0x7fa8bbf25750}, 8) = 0
[pid 24150] rt_sigprocmask(SIG_BLOCK, NULL, [PIPE], 8) = 0
[pid 24150] rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER, 
0x7fa8bbf25750}, {SIG_DFL, [], SA_RESTORER, 0x7fa8bbf25750}, 8) = 0
[pid 24150] rt_sigaction(SIGWINCH, {0x43e710, [], SA_RESTORER, 
0x7fa8bbf25750}, {SIG_DFL, [], 0}, 8) = 0
[pid 24150] rt_sigaction(SIGCHLD, {0x42dcc0, [], SA_RESTORER, 
0x7fa8bbf25750}, {SIG_DFL, [], SA_RESTORER, 0x7fa8bbf25750}, 8) = 0
[pid 24150] rt_sigprocmask(SIG_BLOCK, NULL, [PIPE], 8) = 0
[pid 24150] rt_sigprocmask(SIG_BLOCK, NULL, [PIPE], 8) = 0
[pid 24150] rt_sigprocmask(SIG_BLOCK, NULL, [PIPE], 8) = 0
[pid 24150] rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 
0x7fa8bbf25750}, {SIG_DFL, [], SA_RESTORER, 0x7fa8bbf25750}, 8) = 0
[pid 24150] rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 
0x7fa8bbf25750}, {SIG_IGN, [], SA_RESTORER, 0x7fa8bbf25750}, 8) = 0
[pid 24150] rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 
0x7fa8bbf25750}, {0x42dcc0, [], SA_RESTORER, 0x7fa8bbf25750}, 8) = 0
[pid 24150] execve("/bin/bzip2", ["/bin/bzip2", "-c", "-d", 
"/usr/share/man/man1/strace.1.bz2"], [/* 15 vars */]) = 0
[pid 24150] arch_prctl(ARCH_SET_FS, 0x7f638fe02700) = 0
[pid 24150] rt_sigaction(SIGSEGV, {0x401950, [SEGV], 
SA_RESTORER|SA_RESTART, 0x7f638f6c9750}, {SIG_DFL, [], 0}, 8) = 0
[pid 24150] rt_sigaction(SIGBUS, {0x401950, [BUS], 
SA_RESTORER|SA_RESTART, 0x7f638f6c9750}, {SIG_DFL, [], 0}, 8) = 0
[pid 24149] wait4(24150, Process 24149 suspended

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)
  <unfinished ...>
[pid 24150] exit_group(1)               = ?
Process 24149 resumed
Process 24150 detached
<... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0, NULL) = 
24150
--- SIGCHLD (Child exited) @ 0 (0) ---
/usr/share/man/man1/strace.1.bz2
exit_group(0)                           = ?
$





-- 
WBR, Alexey

Re: [Comm] man через ssh

[Dmitry Chistikov]

Кстати, честно говоря, я не понимаю вот этого (последний write() в stdout
потомка):

> [pid 27496] write(1, " unfinished .\nWhen the call retu"..., 4096) = -32

Почему он возвращает -32, а не -1?

> Да, если не заворачивать все это дело в ssh, то bzip2 молчит. Ниже 
> приведен strace по сигналам, но я не вижу SIGPIPE в листинге
> 
> $ ssh localhost -- strace -f -e trace=signal,process -- man -w strace
> [...]

Он там есть, но не выставляется, а уже наблюдается:

> [pid 24150] rt_sigprocmask(SIG_BLOCK, NULL, [PIPE], 8) = 0

По-видимому, его выставяет sshd? Вообще, в его коде реакция на SIGPIPE
для порождаемых сессий сбрасывается на умолчательный (SIG_DFL) вариант.

Есть ли разница между

$ ssh localhost -- strace -e trace=signal sh -c true

и

$ strace -e trace=signal sh -c true

?

(У меня ее нет и по вызовам rt_sigprocmask видно, что SIGPIPE не
игнорируется).

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

Re: [Comm] man через ssh

[Alexey Bochenin]

24.02.2011 15:55, Dmitry Chistikov пишет:
> Кстати, честно говоря, я не понимаю вот этого (последний write() в stdout
> потомка):
>
>> [pid 27496] write(1, " unfinished .\nWhen the call retu"..., 4096) = -32
>
> Почему он возвращает -32, а не -1?

Не знаю, даже если я доберусь до исходного кода приведенного фрагмента в 
bzip2, я вряд ли разберусь. Могу предположить, что это код ошибки "I/O 
or other error", во всяком случае вроде именно так ругается в дальнейшем 
bzip2


>> Да, если не заворачивать все это дело в ssh, то bzip2 молчит. Ниже
>> приведен strace по сигналам, но я не вижу SIGPIPE в листинге
>>
>> $ ssh localhost -- strace -f -e trace=signal,process -- man -w strace
>> [...]
>
> Он там есть, но не выставляется, а уже наблюдается:
>
>> [pid 24150] rt_sigprocmask(SIG_BLOCK, NULL, [PIPE], 8) = 0
>
> По-видимому, его выставяет sshd? Вообще, в его коде реакция на SIGPIPE
> для порождаемых сессий сбрасывается на умолчательный (SIG_DFL) вариант.
>
> Есть ли разница между
> $ ssh localhost -- strace -e trace=signal sh -c true
> и
>
> $ strace -e trace=signal sh -c true
>
> ?
>
> (У меня ее нет и по вызовам rt_sigprocmask видно, что SIGPIPE не
> игнорируется).
>

Дмитрий, я еще только учусь понимать strace, поэтому поный вывод привел ниже
$ ssh localhost -- strace -e trace=signal sh -c true
rt_sigprocmask(SIG_BLOCK, NULL, [PIPE], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [PIPE], 8) = 0
rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x7f67d5301750}, 
{SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x7f67d5301750}, 
{SIG_DFL, [], SA_RESTORER, 0x7f67d5301750}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f67d5301750}, 
{SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f67d5301750}, 
{SIG_DFL, [], SA_RESTORER, 0x7f67d5301750}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x7f67d5301750}, 
{SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x7f67d5301750}, 
{SIG_DFL, [], SA_RESTORER, 0x7f67d5301750}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [PIPE], 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER, 0x7f67d5301750}, 
{SIG_DFL, [], SA_RESTORER, 0x7f67d5301750}, 8) = 0
rt_sigaction(SIGWINCH, {0x43e710, [], SA_RESTORER, 0x7f67d5301750}, 
{SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGCHLD, {0x42dcc0, [], SA_RESTORER, 0x7f67d5301750}, 
{SIG_DFL, [], SA_RESTORER, 0x7f67d5301750}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [PIPE], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [PIPE], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [PIPE], 8) = 0
$

$ strace -e trace=signal sh -c true
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x7f07ef272750}, 
{SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x7f07ef272750}, 
{SIG_DFL, [], SA_RESTORER, 0x7f07ef272750}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f07ef272750}, 
{SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f07ef272750}, 
{SIG_DFL, [], SA_RESTORER, 0x7f07ef272750}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x7f07ef272750}, 
{SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x7f07ef272750}, 
{SIG_DFL, [], SA_RESTORER, 0x7f07ef272750}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER, 0x7f07ef272750}, 
{SIG_DFL, [], SA_RESTORER, 0x7f07ef272750}, 8) = 0
rt_sigaction(SIGWINCH, {0x43e710, [], SA_RESTORER, 0x7f07ef272750}, 
{SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGCHLD, {0x42dcc0, [], SA_RESTORER, 0x7f07ef272750}, 
{SIG_DFL, [], SA_RESTORER, 0x7f07ef272750}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
$

Кстати, аналогичную ситуацию наблюдается не только в сизифе, но и гноме P5.
$ ssh localhost -- man -w bash

bzip2: I/O or other error, bailing out.  Possible reason follows.
bzip2: Broken pipe
	Input file = /usr/share/man/ru/man1/bash.1.bz2, output file = (stdout)
/usr/share/man/ru/man1/bash.1.bz2
$

Доберусь до 5.1 - проверю и там

-- 
WBR, Alexey

Re: [Comm] man через ssh

[Dmitry Chistikov]

> > Кстати, честно говоря, я не понимаю вот этого (последний write() в stdout
> > потомка):
> >
> >> [pid 27496] write(1, " unfinished .\nWhen the call retu"..., 4096) = -32
> >
> > Почему он возвращает -32, а не -1?
> 
> Не знаю, даже если я доберусь до исходного кода приведенного фрагмента в 
> bzip2, я вряд ли разберусь. Могу предположить, что это код ошибки "I/O 
> or other error", во всяком случае вроде именно так ругается в дальнейшем 
> bzip2

Мое непонимание не имеет отношения к bzip2. write() - это системный вызов,
должен работать заранее известным образом в большинстве стандартных
ситуаций. write() никогда не должен возвращать отрицательных значений,
отличных от -1. Я совершенно не понимаю, откуда взялось число -32.

> Дмитрий, я еще только учусь понимать strace, поэтому поный вывод привел ниже
> $ ssh localhost -- strace -e trace=signal sh -c true
> rt_sigprocmask(SIG_BLOCK, NULL, [PIPE], 8) = 0

Вот здесь смотрим в man этого вызова и видим, что третий аргумент - это
возвращенное значение и оно (при данных параметрах) задает маску
игнорируемых (blocked) сигналов. Таким образом, SIGPIPE как раз
игнорируется.

> $ strace -e trace=signal sh -c true
> rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0

Здесь то же самое, но маска пуста, то есть игнорируемых сигналов нет.

По-видимому, это следы работы sshd (или его "сподвижников" ;)).

> Кстати, аналогичную ситуацию наблюдается не только в сизифе, но и гноме P5.
> [...]
> Доберусь до 5.1 - проверю и там

У меня есть машины с 5.1 и 4.1, на них такого эффекта не наблюдается.

Попробуйте присоединиться (-p) strace'ом (-f -e trace=process,signal) к sshd,
после чего устроить ssh localhost true (вроде все должно быть видно даже в
таком простом варианте) и поглядеть на происходящее. Сам sshd игнорирует
SIGPIPE, но, насколько я понимаю, выставляет умолчательный режим для
запускаемых "через ssh" потомков. У меня это выглядит так (прямо перед
execve("/bin/bash", ...)):

[pid  2878] rt_sigaction(SIGPIPE, NULL, {SIG_IGN, [], 0}, 8) = 0
[pid  2878] rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0

Первый вызов запрашивает, какова реакция на SIGPIPE. Видно, что он
игнорируется (SIG_IGN). Второй вызов устанавливает для этого сигнала
поведение по умолчанию (SIG_DFL) - у SIGPIPE это означает завершение
процесса.

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

Re: [Comm] man через ssh

[Dmitry Chistikov]

> По-видимому, это следы работы sshd (или его "сподвижников" ;)).

Вот, к слову, несколько примеров, почему такого, вообще-то, быть не должно:
http://lists.mindrot.org/pipermail/openssh-unix-dev/2000-December/003484.html
Мне кажется, что если дело действительно в самом sshd, а не, скажем, в его
неудачных настройках, то это бага, которую нужно вешать, искать и исправлять.

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

Re: [Comm] man через ssh

[Alexey Bochenin]

24.02.2011 19:46, Alexey Bochenin пишет:
> Кстати, аналогичную ситуацию наблюдается не только в сизифе, но и гноме P5.
> $ ssh localhost -- man -w bash
>
> bzip2: I/O or other error, bailing out. Possible reason follows.
> bzip2: Broken pipe
> Input file = /usr/share/man/ru/man1/bash.1.bz2, output file = (stdout)
> /usr/share/man/ru/man1/bash.1.bz2
> $
>
> Доберусь до 5.1 - проверю и там

В свежеустановленном в виртуалбоксе 5.1 ошибки нет.

По мотивам 
http://lists.mindrot.org/pipermail/openssh-unix-dev/2000-December/003484.html, 
провел тестирование в виртуальном P5, и broken pipe тут как тут.
[bochenin@host-15 /]$ ssh localhost -- LANG=C yes|head -1
bochenin@localhost's password:
y
yes: standard output: Broken pipe
yes: write error
[bochenin@host-15 /]$

На рабочем компьютере тоже наблюдаю ошибку.
Но после рестарта sshd все исправилось в том числе и проблемы с man 
через ssh.

Итог: причина осталась для меня непонятной, рестарт sshd исправляет 
ситуацию с broken pipe.





-- 
WBR, Alexey

Re: [Comm] man через ssh

[Dmitry Chistikov]

Alexey Bochenin, Feb. 25, 2011, 11:49 +0300:
> Итог: причина осталась для меня непонятной, рестарт sshd исправляет 
> ситуацию с broken pipe.

С тех пор не проявлялось? Начинает ли проявляться снова после, скажем,
перезагрузки?

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

Re: [Comm] man через ssh

[Alexey Bochenin]

03.03.2011 12:45, Dmitry Chistikov пишет:
> Alexey Bochenin, Feb. 25, 2011, 11:49 +0300:
>> Итог: причина осталась для меня непонятной, рестарт sshd исправляет
>> ситуацию с broken pipe.
>
> С тех пор не проявлялось? Начинает ли проявляться снова после, скажем,
> перезагрузки?
>

Я ошибся, и рестарт sshd не повлиял на ситуацию с broken pipe.

Дмитрий, Вы писали насчет странности поведения функции write(...) 
возвращающей -32 вместо стандартно описанного -1.
Обновление до мартовского сизифа в какой-то степени помогло,
ssh localhost -- strace -p -e write man -w bash теперь write возвращает, 
как и описано, -1. Ошибка broken pipe, впрочем, все также присутствует.

Если важно выяснить, начиная с какой версии glibc поменялось поведение 
write (кстати, правильно ли я предположил что write() реализована именно 
в glibс?, если нет - подскажите, за какими файлами наблюдать), то 
используя архив сизифа http://www.altlinux.org/Архив_Сизифа могу 
попытаться определить версию точнее.

$ rpm -qa|grep glibc-|sort
glibc-2.11.3-alt3
glibc-core-2.11.3-alt3
glibc-devel-2.11.3-alt3
glibc-gconv-modules-2.11.3-alt3
glibc-kernheaders-2.6.36-alt5
glibc-locales-2.11.3-alt3
glibc-nss-2.11.3-alt3
glibc-preinstall-2.11.3-alt3
glibc-pthread-2.11.3-alt3
glibc-timezones-2.11.3-alt3
glibc-utils-2.11.3-alt3
i586-glibc-core-2.11.3-alt3
i586-glibc-pthread-2.11.3-alt3


-- 
WBR, Alexey

Re: [Comm] man через ssh

[Dmitry Chistikov]

Alexey Bochenin, Mar. 03, 2011, 13:59 +0300:
> Я ошибся, и рестарт sshd не повлиял на ситуацию с broken pipe.

Я бы вешал багу на openssh. Нужно объяснить, что в качестве следствий
наблюдается некорректная работа, скажем, "yes | head", а также приложить
вывод strace -p PID_OF_SSHD -f -e trace=process,signal за время выполнения
ssh localhost true (неплохо бы вначале убедиться, что в этом выводе
действительно видно, что реакция на SIGPIPE *не* сбрасывается на
умолчательное состояние).

> Дмитрий, Вы писали насчет странности поведения функции write(...) 
> возвращающей -32 вместо стандартно описанного -1.
> Обновление до мартовского сизифа в какой-то степени помогло,
> ssh localhost -- strace -p -e write man -w bash теперь write возвращает, 
> как и описано, -1.

(В данном случае "-p" быть не должно.)

> Если важно выяснить, начиная с какой версии glibc поменялось поведение 
> write (кстати, правильно ли я предположил что write() реализована именно 
> в glibс?, если нет - подскажите, за какими файлами наблюдать), то 
> используя архив сизифа http://www.altlinux.org/Архив_Сизифа могу 
> попытаться определить версию точнее.

write() - это системный вызов, реализованный в ядре, а еще, если верить
intro(2), обертка glibc (посмотрите intro(2) и syscalls(2), там написано
подробнее). Мне кажется, что наблюдавшееся тогда -32 к основному вопросу
прямого отношения не имеет, хотя, конечно, могу и ошибаться.

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

Re: [Comm] man через ssh

[Alexey Bochenin]

03.03.2011 12:45, Dmitry Chistikov пишет:
> С тех пор не проявлялось? Начинает ли проявляться снова после, скажем,
> перезагрузки?
>

Кажется, удалось локализовать проблему.
steps to reproduce:

1. Установить минимальный alt, например, 
sisyphus-1.1.3-20110224-server-light-i586-ru-install-cd.iso (Пользуясь 
возможностью, хочу сказать спасибо rider@, очень удобный дистрибутив)

2.  Добавить пакет pam_mount
apt-get install pam_mount

3. Проверить поведение ssh
$ ssh localhost -- man -w bash
/usr/share/man/man1/bash.1.bz2
$

4. Добавить в файл /etc/pam.d/system-auth-local строки
auth     optional       pam_mount.so
session  optional       pam_mount.so
примерно таким образом:
$ cat /etc/pam.d/system-auth-local
#%PAM-1.0
auth		required	pam_tcb.so shadow fork prefix=$2a$ count=8 nullok
auth     optional       pam_mount.so
account		required	pam_tcb.so shadow fork
password	required	pam_passwdqc.so config=/etc/passwdqc.conf
password	required	pam_tcb.so use_authtok shadow fork prefix=$2a$ count=8 
nullok write_to=tcb
session		required	pam_tcb.so
session		required	pam_mktemp.so
session		required	pam_limits.so
session  optional       pam_mount.so

5. Убедиться в изменении поведения ssh
$ ssh localhost -- man -w bash

bzip2: I/O or other error, bailing out.  Possible reason follows.
bzip2: Broken pipe
	Input file = /usr/share/man/ru/man1/bash.1.bz2, output file = (stdout)
/usr/share/man/ru/man1/bash.1.bz2
$


Как и когда могли попасть строки в /etc/pam.d/system-auth-local? Не 
помню. Скорее всего, при установке из одного из старых срезов 
готовящегося 5.9.9-centaurus. Во всяком случае, на это наталкивает тема
http://lists.altlinux.org/pipermail/community/2009-June/653245.html


-- 
WBR, Alexey

Re: [Comm] man через ssh

[Dmitry Chistikov]

Alexey Bochenin, Mar. 04, 2011, 15:11 +0300:
> Кажется, удалось локализовать проблему.
> steps to reproduce:
> [...]
> Как и когда могли попасть строки в /etc/pam.d/system-auth-local? Не 
> помню. Скорее всего, при установке из одного из старых срезов 
> готовящегося 5.9.9-centaurus. Во всяком случае, на это наталкивает тема
> http://lists.altlinux.org/pipermail/community/2009-June/653245.html

То есть должно ловиться за руку rpmverify -f /etc/pam.d/system-auth-local
при, условно говоря, актуальной версии пакетов в рамках Сизифа или ветки.
(Так?) Ясно, спасибо!

Непонятка в том, что с июня 2009 года много воды утекло, а раз такая фича
попала в одну из бет, то она может по ошибке оказаться и в релизе.
Может кто-нибудь из заинтересованных проверить?

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

Re: [Comm] man через ssh

[Dmitry Chistikov]

Dmitry Chistikov, Mar. 05, 2011, 10:40 +0300:
> То есть должно ловиться за руку rpmverify -f
> /etc/pam.d/system-auth-local при, условно говоря, актуальной версии
> пакетов в рамках Сизифа или ветки.  (Так?) Ясно, спасибо!
> 
> Непонятка в том, что с июня 2009 года много воды утекло, а раз такая фича
> попала в одну из бет, то она может по ошибке оказаться и в релизе.
> Может кто-нибудь из заинтересованных проверить?

Для тех, кому интересно: обсуждение ушло в sisyphus@:
http://lists.altlinux.org/pipermail/sisyphus/2011-March/352950.html

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