Re: Problem z Debianem
On Mon, 12 Jun 2006 08:37:27 +0200, January Weiner wrote:
[...]
> Otóż wyglądało to tak, że ltrace nie dawał żadnych wyników, bo z
> ltrace ls działał prawidłowo. Mój błąd! Porównywałem jabłka i
> pomarańcze. Normalnie w shellu ls jest aliasem do "ls --color",
> podczas gdy "ltrace ls" to to samo co "ltrace /bin/ls", bez opcji.
>
> Otóż gdy się zrobi ltrace /bin/ls --color, wynik jest bardziej jednoznaczny:
>
> sigprocmask(0, 0x805b580, 0xbf8fe9ac) = 0
> signal(13, NULL) = 0x8049ce0
> raise(13, 0, 0xbf8fe9ac, 0xbf8fe9d4, 0xbf8fe9e0) = 0
> sigprocmask(2, 0xbf8fe9ac, NULL <unfinished ...>
> --- SIGPIPE (Broken pipe) ---
> +++ killed by SIGPIPE +++
>
> Podobnie wygląda w przypadku strace. Czyli _jednak_ problemem jest ten
> nieszczęsny limit wielkości pipe (ulimit -p), który ani nie wiem,
> gdzie jest ustawiany, ani go nie potrafię zmienić (" ulimit: pipe
> size: cannot modify limit: Invalid argument"), ani nie wiem, dlaczego
> powoduje SIGPIPE. Nie szkodzi, teraz mogę już sobie poguglać.
Zdziwniej i zdziwniej.
To jest jakiś bashowy pseudolimit nie występujący w rzeczywistości
w jądrze jako modyfikowalny limit dostępności zasobu. Nie zmienisz go więc.
Jeśli u Ciebie wynosi on 8, to jest to normalny rozmiar bufora potoku
(8*512=4096) i nie powinien w niczym przeszkadzać. Zresztą jeśli
jakimś cudem ma inną wartość, to też nie powinno być przecież problemem
powodującym SIGPIPE.
Ciekaw jestem o co tu chodzi, ale mogę tylko życzyć udanego guglania.
Czy ten SIGPIPE rzeczywiście ma swoje źródło w jądrze?
> >Spodziewam się, że wiesz co piszesz
>
> Byłbym ostrożny -- nie jestem administratorem, tylko użytkownikiem
> zmuszonym do administrowania (którego żywo nienawidzę, niezależnie od
> systemu i dystrybucji).
Dobra, dobra, czytelnika pcoa nie musisz o tym informować :-)
--
Michał Politowski
Talking has been known to lead to communication if practiced carelessly.
Reply to: