Re: contrib/start-scripts/linux failing on RHEL 6 with ~9.3 because of missing oom_score_adj

On Sun, Apr 26, 2015 at 10:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>> On Sun, Apr 26, 2015 at 8:47 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> This patch seems completely wrong, as it is forcing use of the oom
>>> adjustment, whereas the intention is that the user should choose
>>> if they want to use it; cf /contrib/start-scripts/linux lines 43-55.
>
>> On REL9_3_STABLE, the condition the startup script has is that:
>> test x"$OOM_SCORE_ADJ" != x && echo "$OOM_SCORE_ADJ" > /proc/self/oom_score_adj
>> test x"$OOM_ADJ" != x && echo "$OOM_ADJ" > /proc/self/oom_adj
>
> Yeah, but by default $OOM_SCORE_ADJ is unset so that the echo is not
> executed. What you are proposing is that if the user has accidentally
> uncommented the wrong one of the two variables, the script should silently
> do nothing instead of failing. I think that's an actively bad idea,
> because then it would be far too hard to notice that you'd misconfigured
> it.

Hm. OK. That sounds like a fair argument as well. The user I got the
complaint from was just complaining about the opposite as service
startup refused to start up with the default values, but in this case
a copy of the startup script is maintained... So that's not a big
deal.

> In any case, I think changing the behavior of the script in stable
> branches would be unwise. People generally will use these things as
> templates, they won't just blindly copy them (at least I hope not);
> and they're unlikely to overwrite an existing live script file when
> installing a minor update release.

OK.

> We have changed the script, hopefully for the better, in HEAD --- if
> you think the behavior still leaves something to be desired, debating
> that would certainly be fair game. (I notice that HEAD *is* using a
> "test -e", which according to my argument above maybe isn't a good thing.)

The behavior in HEAD is far better, and nothing to say about that ;)
Regards,
--
Michael