[Comm] man через ssh

Dmitry Chistikov dd1email на gmail.com
Чт Фев 24 18:28:20 UTC 2011


> > Кстати, честно говоря, я не понимаю вот этого (последний 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 это означает завершение
процесса.

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


Подробная информация о списке рассылки community