pam i sygnały

Jan Rekorajski baggins w sith.mimuw.edu.pl
Czw, 7 Sie 2003, 13:41:35 CEST


On Thu, 07 Aug 2003, Jakub Bogusz wrote:

> On Thu, Aug 07, 2003 at 01:31:20PM +0200, Jan Rekorajski wrote:
> > On Thu, 07 Aug 2003, Jakub Bogusz wrote:
> > > On Wed, Aug 06, 2003 at 03:25:50PM +0200, Jan Rekorajski wrote:
> > > > On Wed, 06 Aug 2003, Paweł Gołaszewski wrote:
> > > > > Przypadkiem dostałem od Adama Tlałki łatkę na pam-a z poprawką działania 
> > > > > pam_unix.
> > > > > Baggins - co ty na to? Zaaplik(ujesz|ować)?
> > > > > qboosh, ty przy tym trochę siedziałeś - to jest do zaakceptowania?
> > > > 
> > > > Trik polega na nie na tym zeby to dzialalo za wszelka cene ale zeby
> > > > ubicie helpera nie wywalalo aplikacji. Jesli ten pacz to zapewnia - a na
> > > > to nie wyglada to jest ok, wedlug mnie poprawne rozwiazanie zaproponowal
> > > > qboosh - czyli wsadzic tam wlasna pusta funkcje obslugi sygnalu.
> > > 
> > > Hm.
> > > Kiedy SIGCHLD mógłby zrobić coś złego? Chyba tylko jeśli program ustawił
> > > wcześniej jego obsługę na jakąś własną procedurę.
> > > Jeśli ustawimy go na SIG_DFL, czyli zgodnie z signal(7) ignorowanie
> > > sygnału (ale nie równoznaczne z ustawieniem na SIG_IGN[1]), to czy
> > > SIGCHLD może wyrządzić jakąś krzywdę? Nie widzę takiej możliwości.
> > 
> > Oj, zawsze mi sie wydawalo ze proces ktory dostal SIGCHLD potrafil ze
> > smutku po zabitym potomku umrzec. Jesli mi sie wydawalo, i SIG_DFL
> > dziala jak chcemy to nie widze przeszkod w zaaplikowaniu pacza.
> 
> Potrafisz odtworzyć taką sytuację?

Chyba nie.

> Może towarzyszyły temu inne okoliczności, np. SIGPIPE.
> Też widywałem przypadki zniknięcia rodzica, ale wątpię, by akurat SIGCHLD
> było tego powodem.

Mozliwe. Moze mi sie tylko wydawalo.

Janek
-- 
Jan Rękorajski            |  ALL SUSPECTS ARE GUILTY. PERIOD!
baggins<at>mimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, MANIAC              |                   -- TROOPS by Kevin Rubio



Więcej informacji o liście dyskusyjnej pld-devel-pl