Thread: 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@commandprompt.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@commandprompt.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@commandprompt.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)