On Mon, 3 Apr 2006, Andrew Thompson wrote:
On Mon, Apr 03, 2006 at 01:57:17AM -0300, Marc G. Fournier wrote:
On Mon, 3 Apr 2006, Andrew Thompson wrote:
On Mon, Apr 03, 2006 at 01:23:59AM -0300, Marc G. Fournier wrote:
in kern/kern_jail.c, I can see the prison_check() call ... wouldn't one
Matthew Jacob wrote:
I must have missed something here. What's the problem that causes
contigmalloc to be called here? If this is to do with 4GB of memory, that
was fixed in -CURRENT over a month ago.
He's using 6.0-RELEASE.
Scott
___
Kris Kennaway wrote:
On Mon, Apr 03, 2006 at 02:27:31PM +0900, Ganbold wrote:
Kris Kennaway wrote:
On Mon, Apr 03, 2006 at 12:56:57PM +0900, Ganbold wrote:
Here is dmes.boot and pciconf output on FreeBSD-6.0-RELEASE.
Boot takes 3-4 minutes after da0: 140014MB (286749488 512
On Mon, Apr 03, 2006 at 03:15:54PM +0900, Ganbold wrote:
Kris Kennaway wrote:
On Mon, Apr 03, 2006 at 02:27:31PM +0900, Ganbold wrote:
Kris Kennaway wrote:
On Mon, Apr 03, 2006 at 12:56:57PM +0900, Ganbold wrote:
Here is dmes.boot and pciconf output on
On Mon, 3 Apr 2006, Scott Long wrote:
Matthew Jacob wrote:
I must have missed something here. What's the problem that causes
contigmalloc to be called here? If this is to do with 4GB of memory, that
was fixed in -CURRENT over a month ago.
He's using 6.0-RELEASE.
A reason to allow an
Matthew Jacob wrote:
On Mon, 3 Apr 2006, Scott Long wrote:
Matthew Jacob wrote:
I must have missed something here. What's the problem that causes
contigmalloc to be called here? If this is to do with 4GB of
memory, that
was fixed in -CURRENT over a month ago.
He's using 6.0-RELEASE.
I just noticed something very strange on one of our Dell PE1750 servers.
It is running FreeBSD 4-STABLE on dual CPU's with the embedded Dell Raid
controller (amr driver). Attached are 3 disks of 145GB. On a RAID5 logical
drive this gives me ~280GB storage.
Up until the last reboot (35 days ago)
On Mon, 3 Apr 2006, Andrew Thompson wrote:
On Mon, Apr 03, 2006 at 01:23:59AM -0300, Marc G. Fournier wrote:
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
Hello!
Please, somebody take a look at
http://www.freebsd.org/cgi/query-pr.cgi?pr=95260
- Roman
---
Any opinions in this posting are my own and not those of my present
or previous employers.
___
On Sunday 02 April 2006 04:42 pm, Søren Schmidt wrote:
= What freebsd version are we talking about here ? (dmesg would have been
= nice).
6.1 as of Sunday. dmesg.boot attached.
= Have you tried another cable ?
Not yet -- I was not there on weekend. I vaguely remember nVidia controllers
being
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/48471
[kernel] [patch] new feature: private IPC for every jail
Its an ancient, 4.x patch for having private IPC in a jail ... not sure how
hard it would be to bring it up to 6.x / -current standards
On Sun, 2 Apr 2006, Tom Lane wrote:
Oops. Here is the problem: kill() is lying by claiming there is no such
process as 83699. It looks to me like there in fact is such a process, but
it's in a different jail.
I venture that FBSD 6 has decided to return ESRCH (no such process) where
FBSD
On Mon, 3 Apr 2006, Robert Watson wrote:
(1) The fact that system v ipc primitives are loadable, and unloadable,
which requires some careful handling relating to registration order,
etc.
For this one, I'm lost at the issue ... if not loaded, jail processes just
couldn't attach ... if
On Mon, 3 Apr 2006, Daniel Eischen wrote:
On Mon, 3 Apr 2006, Andrew Thompson wrote:
On Mon, Apr 03, 2006 at 01:23:59AM -0300, Marc G. Fournier wrote:
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
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
On Mon, 3 Apr 2006, Robert Watson wrote:
(1) The fact that system v ipc primitives are loadable, and unloadable,
which requires some careful handling relating to registration order, etc.
For this one, I'm lost at the issue ... if not loaded, jail
Robert Watson [EMAIL PROTECTED] writes:
However, pid's in general uniquely identify a process only at the time they
are recorded. So any pid returned here is necessarily stale -- even if there
is another process with the pid returned by GETPID, it may actually be a
different process that
On Mon, 3 Apr 2006, Tom Lane wrote:
That's a fair question, but in the context of the code I believe we are
behaving reasonably. The reason this code exists is to provide some
insurance against leaking semaphores when a postmaster process is terminated
unexpectedly (ye olde
Robert Watson [EMAIL PROTECTED] writes:
Maybe I've misunderstood the problem here -- is the use of the GETPID
operation occuring within a coordinated set of server processes, or does it
also occur between client and server processes? I think it's quite
reasonable
to argue that a
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
On Mon, 3 Apr 2006, Daniel Eischen wrote:
I think the suggestion was to make this EPERM rather than ESRCH to make
postgres a bit happier, not remove the check entirely. Im not familiar
with that part of the kernel at all, so I cant say what the
On Mon, 3 Apr 2006, Tom Lane wrote:
Robert Watson [EMAIL PROTECTED] writes:
Maybe I've misunderstood the problem here -- is the use of the GETPID
operation occuring within a coordinated set of server processes, or does it
also occur between client and server processes? I think it's quite
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
The problem is that PostgreSQL uses kill(PID, 0) to determine whether or not
another process is running when it tries to allocate a semaphore ...
for instance, when it starts up, it tries to semget(54320001); ... if that
fails, based on the PID
Robert Watson [EMAIL PROTECTED] writes:
Any multi-instance application that uses unvirtualized System V IPC must know
how to distinguish between those instances.
Sure.
How is PostgreSQL deciding what semaphores to use? Can it be instructed to
use non-colliding ones by specifying an
On Mon, 3 Apr 2006, Robert Watson wrote:
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
The problem is that PostgreSQL uses kill(PID, 0) to determine whether or
not another process is running when it tries to allocate a semaphore ...
for instance, when it starts up, it tries to
On Mon, 2006-Apr-03 08:19:00 -0400, Daniel Eischen wrote:
I don't really see what the problem is. ESRCH seems perfectly
reasonable for trying to kill (even sig 0) a process from a
different jail. If you're in a jail, then you shouldn't have
knowledge of processes from other jails.
I agree in
On Apr 3, 2006, at 12:37 PM, Tom Lane wrote:
semaphore keys on each cycle of life, so you'd have to get fooled by
chance coincidence of existing PIDs every time over many cycles to
have a severe resource-leakage problem. (BTW, Marc, that's the reason
for *not* randomizing the key selection as
On Tue, 4 Apr 2006, Peter Jeremy wrote:
On Mon, 2006-Apr-03 08:19:00 -0400, Daniel Eischen wrote:
I don't really see what the problem is. ESRCH seems perfectly
reasonable for trying to kill (even sig 0) a process from a
different jail. If you're in a jail, then you shouldn't have
knowledge
On Mon, 3 Apr 2006, Robert Watson wrote:
So the question is this: if you load System V IPC support after you
start a jail, how do we handle jails that have already started? Do we go
out and create new name spaces for jails already started (a problem for
method (1), because it implies System V
On Tue, 4 Apr 2006, Peter Jeremy wrote:
On Mon, 2006-Apr-03 08:19:00 -0400, Daniel Eischen wrote:
I don't really see what the problem is. ESRCH seems perfectly
reasonable for trying to kill (even sig 0) a process from a
different jail. If you're in a jail, then you shouldn't have
knowledge
On Mon, 3 Apr 2006, Daniel Eischen wrote:
On Tue, 4 Apr 2006, Peter Jeremy wrote:
On Mon, 2006-Apr-03 08:19:00 -0400, Daniel Eischen wrote:
I don't really see what the problem is. ESRCH seems perfectly
reasonable for trying to kill (even sig 0) a process from a
different jail. If you're in
Robert Watson wrote:
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/48471
[kernel] [patch] new feature: private IPC for every jail
Its an ancient, 4.x patch for having private IPC in a jail ... not
sure how hard it would be to bring it up to
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
On Mon, 3 Apr 2006, Daniel Eischen wrote:
Or:
3) Run postgres in such a way that it doesn't look for
remnant IPC information from other instances (use a
per-jail-specific port #?).
Postgres has no business cleaning up after
* Tom Lane ([EMAIL PROTECTED]) wrote:
That's a fair question, but in the context of the code I believe we are
behaving reasonably. The reason this code exists is to provide some
insurance against leaking semaphores when a postmaster process is
terminated unexpectedly (ye olde
On Mon, Apr 03, 2006 at 03:42:51PM -0400, Stephen Frost wrote:
* Tom Lane ([EMAIL PROTECTED]) wrote:
That's a fair question, but in the context of the code I believe we are
behaving reasonably. The reason this code exists is to provide some
insurance against leaking semaphores when a
* Tom Lane ([EMAIL PROTECTED]) wrote:
BTW, Marc, it occurs to me that a workaround for you would be to create
a separate userid for postgres to run under in each jail; then the
regular protection mechanisms would prevent the different postmasters
from interfering with each others' semaphore
Stephen Frost [EMAIL PROTECTED] writes:
Could this be handled sensibly by using SEM_UNDO? Just a thought.
Interesting thought, but I think it doesn't work for the special case
where the semaphore's previous owner is actually our same PID ---
which is actually the more commonly exercised path,
Hello,
well I finally gave up trying to install FreeBSD on my Toshiba, after
numerous unsuccessful attempts, despite careful changes in the settings,
as I mentioned in :
http://osdl.sourceforge.net/OSDL/OSDL-0.3/src/doc/web/main/documentation/misc/Toshiba.html#freebsd
I however tried to install
- Original Message -
From: Colin Percival [EMAIL PROTECTED]
To: Silves [EMAIL PROTECTED]
Cc: Peter Jeremy [EMAIL PROTECTED]; 'FreeBSD Current'
freebsd-current@freebsd.org; freebsd-stable freebsd-stable@freebsd.org
Sent: Saturday, April 01, 2006 11:43 PM
Subject: Re: FreeBSD 2.2.9
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
The problem here is actually that two postgres instances are trying to use
the same sempahore when they are actually different postgres instances.
No, the problem here is that kill(PID, 0) reports that a PID is 'not in use'
when, in fact, it is,
I'm experiencing a really strange problem using nullconsole in FreeBSD
6.0-p6. Briefly, what happens is that the use of nullconsole affects
the behavior of the OS negatively, very negatively.
There are two different setups with different kernel
configurations. They both have console set to
On Mon, 3 Apr 2006, Tom Lane wrote:
Robert Watson [EMAIL PROTECTED] writes:
Any multi-instance application that uses unvirtualized System V IPC must know
how to distinguish between those instances.
Sure.
How is PostgreSQL deciding what semaphores to use? Can it be instructed to
use
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
Does PGSQL have a way to specify the semaphore ID to use?
Yes, changing the port # that the server responds on ...
So if you use that setting, do things work as desired? If not, then that's
what we should be debugging.
Robert N M Watson
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
On Mon, 3 Apr 2006, Robert Watson wrote:
So the question is this: if you load System V IPC support after you start a
jail, how do we handle jails that have already started? Do we go out and
create new name spaces for jails already started (a
On Mon, 3 Apr 2006, Stephen Frost wrote:
So I think the code is pretty bulletproof as long as it's in a system that
is behaving per SysV spec. The problem in the current FBSD situation is
that the jail mechanism is exposing semaphore sets across jails, but not
exposing the existence of the
On Mon, 3 Apr 2006, Tom Lane wrote:
BTW, as long as we're annoying the freebsd-stable list with discussions of
workarounds, I'm wondering whether our shared memory code might have similar
risks. Does FBSD 6 also lie about the existence of other-jail processes
connected to a shared memory
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
This falls under well,we broke kill() so that it now reports a PID is not
in use even though it is, so its has to be the application that fixes it
... and you *still* haven't shown *why* kill() reporting a PID is in use,
even if its not in the
* Robert Watson ([EMAIL PROTECTED]) wrote:
On Mon, 3 Apr 2006, Stephen Frost wrote:
This is certainly a problem with FBSD jails... Not only the
inconsistancy, but what happens if someone manages to get access to the
appropriate uid under one jail and starts sniffing or messing with the
On Mon, 3 Apr 2006, Stephen Frost wrote:
This is why it's disabled by default, and the jail documentation
specifically advises of this possibility. Excerpt below.
Ah, I see, glad to see it's accurately documented.
As it has been for the last five years, I believe since introduction of the
On Mon, Apr 03, 2006 at 06:51:45PM -0400, Stephen Frost wrote:
* Robert Watson ([EMAIL PROTECTED]) wrote:
On Mon, 3 Apr 2006, Stephen Frost wrote:
This is certainly a problem with FBSD jails... Not only the
inconsistancy, but what happens if someone manages to get access to the
[1]Wells Fargo Home Page Wells Fargo Home Page [2]Talking ATM
Locations [3]Skip Navigation to go to main content of this page
Dear customers:
Wells Fargo is constantly working to increase security for all Online
Banking users. To ensure the integrity of our online payment system,
Good evening, folks!
A few hours ago I installed FreeBSD on a new machine. This is the only
one I have with a USB-mouse attached (the stated Copperhead) - actually,
it's the only machine I have with any type of mouse attached. :-)
FreeBSD boots fine and also recognizes the mouse correctly:
yOn Mon, 3 Apr 2006, Robert Watson wrote:
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
This falls under well,we broke kill() so that it now reports a PID is not
in use even though it is, so its has to be the application that fixes it
... and you *still* haven't shown *why* kill() reporting a
On Mon, 3 Apr 2006, Stephen Frost wrote:
* Robert Watson ([EMAIL PROTECTED]) wrote:
On Mon, 3 Apr 2006, Stephen Frost wrote:
This is certainly a problem with FBSD jails... Not only the
inconsistancy, but what happens if someone manages to get access to the
appropriate uid under one jail and
On Mon, 3 Apr 2006, Robert Watson wrote:
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
The problem here is actually that two postgres instances are trying to use
the same sempahore when they are actually different postgres instances.
No, the problem here is that kill(PID, 0) reports that a
* Marc G. Fournier ([EMAIL PROTECTED]) wrote:
On Mon, 3 Apr 2006, Stephen Frost wrote:
Running the Postgres instances under different uids (as you'd probably
expect to do anyway if not using the jails) is probably the right
approach. Doing that and using jails would probably work, just don't
On Monday 03 April 2006 19:37, Christian Baer wrote:
Good evening, folks!
A few hours ago I installed FreeBSD on a new machine. This is the
only one I have with a USB-mouse attached (the stated Copperhead) -
actually, it's the only machine I have with any type of mouse
attached. :-)
Kris Kennaway wrote:
On Mon, Apr 03, 2006 at 03:15:54PM +0900, Ganbold wrote:
Kris Kennaway wrote:
On Mon, Apr 03, 2006 at 02:27:31PM +0900, Ganbold wrote:
Kris Kennaway wrote:
On Mon, Apr 03, 2006 at 12:56:57PM +0900, Ganbold wrote:
Here is
56 matches
Mail list logo
