Thread: pg_dump silently fails
I've been wresting with this problem since 8.0.1 and am able to
duplicate it on 6 different installations. If I compile postgres from
source, everything works fine. If I install the RHEL 4 ES RPM, pg_dump
silently fails. I've attached two straces, one from 8.0.3 RPM that
fails, and one from 8.0.1 that I compiled that doesn't fail (I didn't
recompile 8.0.3 from source, but I've experienced this with both 8.0.1
and 8.0.2, so I'm guessing it also works with 8.0.3).
In my previous conversations with Devrim, he pointed out that this looks
like the line that's causing it to fail:
fstat64(1, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbff0c6ec) = -1 ENOTTY
(Inappropriate ioctl for device)
I assumed that it was just my machine that had a problem, but since,
I've installed it on 5 other RHEL machines and every single one has had
the same problem.
Thanks,
Brandon
Attachment
Brandon Keepers <brandon@opensoul.org> writes:
> I've been wresting with this problem since 8.0.1 and am able to
> duplicate it on 6 different installations. If I compile postgres from
> source, everything works fine. If I install the RHEL 4 ES RPM, pg_dump
> silently fails.
Is SELinux in enforcement mode, and if so does turning it off change
things?
regards, tom lane
Tom Lane wrote: > Brandon Keepers <brandon@opensoul.org> writes: > > I've been wresting with this problem since 8.0.1 and am able to > > duplicate it on 6 different installations. If I compile postgres from > > source, everything works fine. If I install the RHEL 4 ES RPM, pg_dump > > silently fails. > > Is SELinux in enforcement mode, and if so does turning it off change > things? Should we check for a buggy SELinux and report a meaningful error message on failure? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> Is SELinux in enforcement mode, and if so does turning it off change
>> things?
> Should we check for a buggy SELinux and report a meaningful error
> message on failure?
How you intend to do that, exactly? The bug is that it won't let you
write on /dev/tty, which puts a pretty severe crimp on *any* reporting.
(This is not as insane as it sounds: it's a reasonable security
restriction for a daemon process. The error in older SELinux policy
files is that they think all the Postgres executables are daemons, not
only the postmaster.)
regards, tom lane
On Tue, 2005-06-14 at 13:55 -0400, Tom Lane wrote: > Is SELinux in enforcement mode, and if so does turning it off change > things? Yup, that was it. If you disable SELinux, everything works. I tried just commenting out line 732 in /etc/selinux/targeted/contexts/files/file_contexts and that didn't work. Anyone know how to correct this? Brandon
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> Is SELinux in enforcement mode, and if so does turning it off change > >> things? > > > Should we check for a buggy SELinux and report a meaningful error > > message on failure? > > How you intend to do that, exactly? The bug is that it won't let you > write on /dev/tty, which puts a pretty severe crimp on *any* reporting. > > (This is not as insane as it sounds: it's a reasonable security > restriction for a daemon process. The error in older SELinux policy > files is that they think all the Postgres executables are daemons, not > only the postmaster.) Throw a message to stderr saying something about SELinux. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> How you intend to do that, exactly? The bug is that it won't let you
>> write on /dev/tty, which puts a pretty severe crimp on *any* reporting.
> Throw a message to stderr saying something about SELinux.
Unless stderr is pointing somewhere else than /dev/tty, this will
accomplish exactly zero ... and if it is pointing somewhere else,
then the problem doesn't arise.
regards, tom lane
Brandon Keepers <brandon@opensoul.org> writes:
> Yup, that was it. If you disable SELinux, everything works. I tried
> just commenting out line 732
> in /etc/selinux/targeted/contexts/files/file_contexts and that didn't
> work. Anyone know how to correct this?
I don't know very much about SELinux, but I think the stuff under
/etc/selinux is in the nature of "source code", and if you edit it
you have to do something to compile it and then load the compiled
representation into the kernel.
However, the real answer for your problem is to update to a later
version of selinux-policy-targeted. Red Hat fixed this awhile ago...
regards, tom lane
* Bruce Momjian <pgman@candle.pha.pa.us> [140605, 14:00]:
> Tom Lane wrote:
> > Brandon Keepers <brandon@opensoul.org> writes:
> > > I've been wresting with this problem since 8.0.1 and am able to
> > > duplicate it on 6 different installations. If I compile postgres from
> > > source, everything works fine. If I install the RHEL 4 ES RPM, pg_dump
> > > silently fails.
> >
> > Is SELinux in enforcement mode, and if so does turning it off change
> > things?
>
> Should we check for a buggy SELinux and report a meaningful error
> message on failure?
>
Sorry to interfere ;)
You might be interested to know that there was a complaint about SELinux
blocking OpenOffice too. See ML 'users@openoffice.org' June 13 'Previously
working OOo ...'
Regards,
Ennio.
--
[Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo. \\?//
Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ] (°|°)
[Why use Win$ozz (I say) if ... "even a fool can do that. )=(
Do something you aren't good at!" (as Henry Miller used to say) ]