Re: silent_mode and LINUX_OOM_ADJ

While reviewing Peter Geoghegan's postmaster death patch, I noticed that
if you turn on silent_mode, the LINUX_OOM_ADJ code in fork_process()
runs when postmaster forks itself into background. That re-enables the
OOM killer in postmaster, if you've disabled it in the startup script by
adjusting /proc/self/oom_adj. That seems like a bug, albeit a pretty
minor one.

This may be a dumb question, but what is the purpose of silent_mode?
Can't you just use nohup?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Excerpts from Heikki Linnakangas's message of vie jun 24 07:01:57 -0400 2011:
> While reviewing Peter Geoghegan's postmaster death patch, I noticed that
> if you turn on silent_mode, the LINUX_OOM_ADJ code in fork_process()
> runs when postmaster forks itself into background. That re-enables the
> OOM killer in postmaster, if you've disabled it in the startup script by
> adjusting /proc/self/oom_adj. That seems like a bug, albeit a pretty
> minor one.
>
> This may be a dumb question, but what is the purpose of silent_mode?
> Can't you just use nohup?

I think silent_mode is an artifact from when our daemon handling in
general was a lot more primitive (I bet there wasn't even pg_ctl then).
Maybe we could discuss removing it altogether.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Fri, Jun 24, 2011 at 16:37, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Excerpts from Heikki Linnakangas's message of vie jun 24 07:01:57 -0400 2011:
>> While reviewing Peter Geoghegan's postmaster death patch, I noticed that
>> if you turn on silent_mode, the LINUX_OOM_ADJ code in fork_process()
>> runs when postmaster forks itself into background. That re-enables the
>> OOM killer in postmaster, if you've disabled it in the startup script by
>> adjusting /proc/self/oom_adj. That seems like a bug, albeit a pretty
>> minor one.
>>
>> This may be a dumb question, but what is the purpose of silent_mode?
>> Can't you just use nohup?
>
> I think silent_mode is an artifact from when our daemon handling in
> general was a lot more primitive (I bet there wasn't even pg_ctl then).
> Maybe we could discuss removing it altogether.

If I'm not entirely mistaken, it's on by default in SuSE RPMs. I don't
have a box with access right now, but I've come across it a couple of
times recently with clients, and I think that's how it is. Might want
to doublecheck with the suse maintainer if there's a particular reason
they do that...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On 27.06.2011 10:23, Magnus Hagander wrote:
> On Fri, Jun 24, 2011 at 16:37, Alvaro Herrera
> <alvherre(at)commandprompt(dot)com> wrote:
>> Excerpts from Heikki Linnakangas's message of vie jun 24 07:01:57 -0400 2011:
>>> While reviewing Peter Geoghegan's postmaster death patch, I noticed that
>>> if you turn on silent_mode, the LINUX_OOM_ADJ code in fork_process()
>>> runs when postmaster forks itself into background. That re-enables the
>>> OOM killer in postmaster, if you've disabled it in the startup script by
>>> adjusting /proc/self/oom_adj. That seems like a bug, albeit a pretty
>>> minor one.
>>>
>>> This may be a dumb question, but what is the purpose of silent_mode?
>>> Can't you just use nohup?
>>
>> I think silent_mode is an artifact from when our daemon handling in
>> general was a lot more primitive (I bet there wasn't even pg_ctl then).
>> Maybe we could discuss removing it altogether.
>
> If I'm not entirely mistaken, it's on by default in SuSE RPMs. I don't
> have a box with access right now, but I've come across it a couple of
> times recently with clients, and I think that's how it is. Might want
> to doublecheck with the suse maintainer if there's a particular reason
> they do that...

Yep, seems to be so. Max, you're the maintainer of the PostgreSQL SuSE
RPMs, right? Can you comment on the above?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Hi Heikki,

On Mon, 27 Jun 2011 at 12:10, Heikki Linnakangas wrote:

> Max, you're the maintainer of the PostgreSQL SuSE RPMs, right?

my first name is Reinhard, but aside from that, you are right. ;)

> Can you comment on the above?

I enabled it many years ago when (IIRC) it was needed in conjunction
with "logging_collector = on" to get proper logging and especially log
rotation. It might very well be that it is not needed anymore and
suggestions for doing it better are welcome.

cu
Reinhard

--
SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

On 27.06.2011 12:38, Reinhard Max wrote:
> On Mon, 27 Jun 2011 at 12:10, Heikki Linnakangas wrote:
>
>> Max, you're the maintainer of the PostgreSQL SuSE RPMs, right?
>
> my first name is Reinhard, but aside from that, you are right. ;)

Sorry :-)

>> Can you comment on the above?
>
> I enabled it many years ago when (IIRC) it was needed in conjunction
> with "logging_collector = on" to get proper logging and especially log
> rotation. It might very well be that it is not needed anymore and
> suggestions for doing it better are welcome.

It seems to me you could just stop setting silent_mode. If you want to
capture any early errors at startup into a log file, like silent_mode
does to postmaster.log, you can redirect stdout and stderr in the
startup script. pg_ctl start -l postmaster.log will do the same.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Tue, 28 Jun 2011 at 10:40, Heikki Linnakangas wrote:

> It seems to me you could just stop setting silent_mode. If you want
> to capture any early errors at startup into a log file, like
> silent_mode does to postmaster.log, you can redirect stdout and
> stderr in the startup script. pg_ctl start -l postmaster.log will do
> the same.

OK, thanks. I'll try that next time I touch the packages.

cu
Reinhard

--
SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)