taking it off of pgsql-hackers, so that we don't annoy them unnecessarily
...
'k, looking at the code, not that most of it doesn't go over my head ...
but ...
in kern/kern_jail.c, I can see the prison_check() call ... wouldn't one
want to make the change a bit further up? say in kern_prot.c? wouldn't
you want to change just cr_cansignal() to allow *just* for 'case 0', when
someone is just checking to see if a process is already running? I
wouldn't want to be able to SIGKILL the process from a different jail,
mind you ... maybe move the check for SIG0 to just before the
prison_check, since, unless I'm missing something, other then determining
that a process is, in fact, running, SIG0 is a benign signal?
On Mon, 3 Apr 2006, Andrew Thompson wrote:
On Sun, Apr 02, 2006 at 11:41:01PM -0400, Kris Kennaway wrote:
On Mon, Apr 03, 2006 at 12:30:58AM -0300, Marc G. Fournier wrote:
'k, but how do I fix kill so that it has the proper behaviour if SysV is
enabled?
Check the source, perhaps there's already a way. If not, talk to
whoever made the change.
Maybe a mount option for procfs that allows for pre-5.x
behaviour?
procfs has nothing to do with this though.
I'm not the first one to point out that this is a problem, just
the first to follow it through to the cause ;( And I believe there is
more then just PostgreSQL that is affected by shared memory (ie. apache2
needs SysV IPC enabled, so anyone doing that in a jail has it enabled
also) ...
Also note that SysV IPC is not the problem here, it's the change in
the behaviour of kill() that is causing postgresql to become confused.
That's what you should investigate.
The ESRCH error is being returned from prison_check(), that would be a
good starting place.
Andrew
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
