On 05/31/2012 12:45 AM, Bart Lateur wrote:
>> Alan Hodgson<ahodgson@simkin.ca> writes:
>>> On Wednesday, May 30, 2012 08:22:58 PM Bart Lateur wrote:
>>>> Luckily this is a development machine, but as we don't know what
>>>> causes the problem we fear we might one day face the exact same
>>>> problem where it does matter: on a production machine. So we'd like
>>>> to know exactly what went wrong..
>>
>>> Change selinux to permissive instead of enforcing and see if
>>> PostgreSQL then runs. If it does, you can look at the selinux logging
>>> to see what would have been denied in enforcing mode, and hopefully fix
> it from there.
>>
>> Yeah, I concur that this smells like a selinux issue. Most likely, the
> software update you did messed up the selinux "context" settings for some
> files. restorecon should be able to fix it for you, if so.
>> As Alan says, the kernel log (or separate avc log, depending on how your
> system is set up) should show evidence of the problem if this is where it
> is.
>
> I thought the same, and I was happy to go in and fix it, but then I found
> that SElinux was not even enabled.
>
> Hunting around for more logs I finally found a recently updated log file in
> the subdirectory /var/lib/pgsql/data/pg_log/. And there I found the message
> that pg_hba.conf could not be loaded due to a syntax error in it. Weird, it
> was running before...?
>
> It's suboptimal that starting Postgres fails silently. It's also less than
> optimal that the location of the log files is a bit of a secret. It's also
> suboptimal that Postgres refuses to run because it doesn't understand 1 line
> in pg_hba.conf. After all, it's just a data grid, not prose...
Actually it did not fail silently, it recorded it to the log. The
location of the log file is no great secret, open postgresql.conf(the
server confog file) and look for log_directory. pg_hba.conf is access
control and the first line of defense in security. I would prefer that
it fail closed instead of open.
>
> Anyway, hint for Postgres newbies (or at least, people who don't spend whole
> days administering Postgres, which is about everybody, I guess): find the
> logs. They're in the subdirectory pg_log and they have names like
> "postgresql-DDD.log" where DDD is the three letter name of the day. The
> currently active log is one of them.
Not necessarily. It depends on how Postgres was packaged. See hint above
about looking in postgresql.conf.
>
> Thanks a lot, all of you who replied.
>
--
Adrian Klaver
adrian.klaver@gmail.com