Thread: exit status 26
Can someone tell me what a postmaster process exiting with status = 26
means? FWIW, I'm doing a COPY table FROM stdin with about 14 million
records to trigger this.
Thanks,
-Dan
--
Man is a rational animal who always loses his temper when he is called
upon to act in accordance with the dictates of reason.
-- Oscar Wilde
Dan Moschuk <dan@freebsd.org> writes:
> Can someone tell me what a postmaster process exiting with status = 26
> means? FWIW, I'm doing a COPY table FROM stdin with about 14 million
> records to trigger this.
That means it got a signal 26. Since you didn't mention what platform
you are on, I'm not going to guess what signal that actually is on
your Unix. How about you look in /usr/include/signal.h and/or
/usr/include/sys/signal.h and tell us?
regards, tom lane
| > Can someone tell me what a postmaster process exiting with status = 26
| > means? FWIW, I'm doing a COPY table FROM stdin with about 14 million
| > records to trigger this.
|
| That means it got a signal 26. Since you didn't mention what platform
| you are on, I'm not going to guess what signal that actually is on
| your Unix. How about you look in /usr/include/signal.h and/or
| /usr/include/sys/signal.h and tell us?
Oh, sorry, for some reason I thought status = exit code.
Signal 26 on FreeBSD is SIGVTARLM.
--
Man is a rational animal who always loses his temper when he is called
upon to act in accordance with the dictates of reason.
-- Oscar Wilde
Dan Moschuk <dan@freebsd.org> writes:
> | > Can someone tell me what a postmaster process exiting with status = 26
> | > means? FWIW, I'm doing a COPY table FROM stdin with about 14 million
> | > records to trigger this.
> |
> | That means it got a signal 26.
> Oh, sorry, for some reason I thought status = exit code.
Postgres doesn't use exit codes higher than 2, so I'm supposing that the
reported code must be a signal code.
> Signal 26 on FreeBSD is SIGVTARLM.
We don't ever set a virtual timer alarm, either. Is it possible that
you are running the postmaster with a ulimit-style limit on total
process runtime?
regards, tom lane
| > Signal 26 on FreeBSD is SIGVTARLM.
|
| We don't ever set a virtual timer alarm, either. Is it possible that
| you are running the postmaster with a ulimit-style limit on total
| process runtime?
No, I've tested this and postmaster is being started in an unlimited
enviornment.
The code that delivers the actual signal looks like this:
if (CLKF_USERMODE(frame) &&
timevalisset(&pstats->p_timer[ITIMER_VIRTUAL].it_value) &&
itimerdecr(&pstats->p_timer[ITIMER_VIRTUAL], tick) == 0)
psignal(p, SIGVTALRM);
So it is getting a virtual timer from somewhere. A grep of the backend
directory revealed no setitimer() occurances, so I can confirm that it
isn't postmaster doing it. And if the shells environment is unlimited,
which doesn't leave very many culprits left. :/
--
Man is a rational animal who always loses his temper when he is called
upon to act in accordance with the dictates of reason.
-- Oscar Wilde
Dan Moschuk <dan@freebsd.org> writes:
> So it is getting a virtual timer from somewhere. A grep of the backend
> directory revealed no setitimer() occurances, so I can confirm that it
> isn't postmaster doing it. And if the shells environment is unlimited,
> which doesn't leave very many culprits left. :/
Yes. It would be good to question my assumption that the exit code
is a signal --- I can't see what else it could be, but can you run
the backend with a breakpoint set at exit(), and get a backtrace?
regards, tom lane
| > So it is getting a virtual timer from somewhere. A grep of the backend
| > directory revealed no setitimer() occurances, so I can confirm that it
| > isn't postmaster doing it. And if the shells environment is unlimited,
| > which doesn't leave very many culprits left. :/
|
| Yes. It would be good to question my assumption that the exit code
| is a signal --- I can't see what else it could be, but can you run
| the backend with a breakpoint set at exit(), and get a backtrace?
Unfortunately, after upgrading the machine to 4.2-RELEASE, I cannot reproduce
this problem any longer. :/
If anyone has a 4.1-RELEASE machine kicking around, I'd love to be able
to try and track this down further.
-Dan
--
Man is a rational animal who always loses his temper when he is called
upon to act in accordance with the dictates of reason.
-- Oscar Wilde
Dan Moschuk <dan@freebsd.org> writes:
> | > So it is getting a virtual timer from somewhere. A grep of the backend
> | > directory revealed no setitimer() occurances, so I can confirm that it
> | > isn't postmaster doing it. And if the shells environment is unlimited,
> | > which doesn't leave very many culprits left. :/
> |
> | Yes. It would be good to question my assumption that the exit code
> | is a signal --- I can't see what else it could be, but can you run
> | the backend with a breakpoint set at exit(), and get a backtrace?
> Unfortunately, after upgrading the machine to 4.2-RELEASE, I cannot reproduce
> this problem any longer. :/
> If anyone has a 4.1-RELEASE machine kicking around, I'd love to be able
> to try and track this down further.
I know we've got plenty of FreeBSD people on this list; surely someone
can lend you an account on a 4.1 machine. I changed the Subject: line
just to get the right peoples' attention ...
regards, tom lane
On Fri, Jan 12, 2001 at 03:49:36PM -0500, Tom Lane wrote: > > If anyone has a 4.1-RELEASE machine kicking around, I'd love to be able > > to try and track this down further. > > I know we've got plenty of FreeBSD people on this list; surely someone > can lend you an account on a 4.1 machine. I changed the Subject: line > just to get the right peoples' attention ... i have a 4.1-STABLE circa Sep-12-2000 -- [ Jim Mercer jim@pneumonoultramicroscopicsilicovolcanoconiosis.ca ] [ Reptilian Research -- Longer Life through Colder Blood ] [ aka jim@reptiles.org +1 416 410-5633 ]
* Tom Lane <tgl@sss.pgh.pa.us> [010112 12:54] wrote: > Dan Moschuk <dan@freebsd.org> writes: > > | > So it is getting a virtual timer from somewhere. A grep of the backend > > | > directory revealed no setitimer() occurances, so I can confirm that it > > | > isn't postmaster doing it. And if the shells environment is unlimited, > > | > which doesn't leave very many culprits left. :/ > > | > > | Yes. It would be good to question my assumption that the exit code > > | is a signal --- I can't see what else it could be, but can you run > > | the backend with a breakpoint set at exit(), and get a backtrace? > > > Unfortunately, after upgrading the machine to 4.2-RELEASE, I cannot reproduce > > this problem any longer. :/ > > > If anyone has a 4.1-RELEASE machine kicking around, I'd love to be able > > to try and track this down further. > > I know we've got plenty of FreeBSD people on this list; surely someone > can lend you an account on a 4.1 machine. I changed the Subject: line > just to get the right peoples' attention ... If the bug seems to be in FreeBSD 4.1 and fixed in 4.2 I don't see the point of you trying to track down a bad interaction between the host OS and Postgresql for an older release. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk."
| > I know we've got plenty of FreeBSD people on this list; surely someone
| > can lend you an account on a 4.1 machine. I changed the Subject: line
| > just to get the right peoples' attention ...
|
| If the bug seems to be in FreeBSD 4.1 and fixed in 4.2 I don't see
| the point of you trying to track down a bad interaction between the
| host OS and Postgresql for an older release.
Because I'd like to verify that it was in fact a bug with 4.1 and not
something else.
--
Man is a rational animal who always loses his temper when he is called
upon to act in accordance with the dictates of reason.
-- Oscar Wilde
Dan Moschuk <dan@freebsd.org> writes:
> | If the bug seems to be in FreeBSD 4.1 and fixed in 4.2 I don't see
> | the point of you trying to track down a bad interaction between the
> | host OS and Postgresql for an older release.
> Because I'd like to verify that it was in fact a bug with 4.1 and not
> something else.
Even if it is a since-fixed 4.1 bug, there are doubtless still people
out there running 4.1, to say nothing of other *BSD and less-closely-
related Unixen that may have the same or similar bug. If Dan can
isolate the problem and identify a reasonable workaround, we should
probably put the workaround into Postgres.
regards, tom lane