[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

[@ 2011-02-24 19:08 UTC (permalink / raw)]

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

[@ 2011-02-25 8:49 UTC (permalink / raw)]

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

[@ 2011-03-03 9:45 UTC (permalink / raw)]

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

[@ 2011-03-03 10:59 UTC (permalink / raw)]

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

[@ 2011-03-03 11:32 UTC (permalink / raw)]

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

[@ 2011-03-04 12:11 UTC (permalink / raw)]

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

[@ 2011-03-05 7:40 UTC (permalink / raw)]

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

[@ 2011-03-28 10:58 UTC (permalink / raw)]