[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cobalt-users] Suspending users & sites
- Subject: Re: [cobalt-users] Suspending users & sites
- From: flash22@xxxxxxx
- Date: Tue May 8 14:27:13 2001
- List-id: Mailing list for users to share thoughts on Cobalt products. <cobalt-users.list.cobalt.com>
On Tue, 8 May 2001, shimi wrote:
>
> On Tue, 8 May 2001, Steve Werby wrote:
> You're not necessarily correct about that... once the PID table gets full
> you return to the begining, and then what? :)
Not only that, some processes fork 'backwards' , the original PID becomes
the 'child' and new new pid becomes effective parent...There's no
guarentee that the 'first' pid is the right one. the only guarentee is if
you are killing the pic in the /var/pif file if the process creates it for
you, then it's the process responsability to make certain it's the right
one. killall has no idea....
>
> besides, we're talking on well programmed software and even the init
> scripts does something similar with the daemon start I think... not
> sure...
The init script's use the lock/pid files whenever possible, unfortunatly,
the one for sendmail sucketh bigtime ;-
>
> again, I've tried this on every service possible under linux in the past 3
> years... it had yet to fail me, and that's why I suggested it :-)
You can do this and get away with it by being lucky, and still not really
have a reason to say 'it always works'. There is a window of uncertainty
when a process forks, sendmail blocks signals to it's children, but in
fact , the children do this themselves after forking. If you were to do it
at 'exactly' the right time, you could send the signal to the child, the
parent, or both simultanously (remember the process image gets copied
during forking, this includes the process signal flags on some
machines)....
gsh