similar to: persistent change of max_stack_depth

Hi Thomas, > Could anybody point me in the right direction for setting the kernel > parameter, max_stack_depth, to 10240 for database tuning? > > I have currently set it by running 'ulimit -s 10240' but this does not > survive a reboot. > > Thanks for the response, I've been nosing around that file recently but noted the first two lines; #This file sets the

Hi Jason, On 14/08/15 16:45, Jason Warr wrote: > On Fri, 2015-08-14 at 16:31 +0100, Michael H wrote: >> Hi Thomas, >> >> >>> Could anybody point me in the right direction for setting the kernel >>> parameter, max_stack_depth, to 10240 for database tuning? >>> >>> I have currently set it by running 'ulimit -s 10240' but this does not

Hi All, >>>>> Could anybody point me in the right direction for setting the kernel >>>>> parameter, max_stack_depth, to 10240 for database tuning? >>>>> >>>>> I have currently set it by running 'ulimit -s 10240' but this does not >>>>> survive a reboot. >>>>> >>>>> >>>>

On Aug 14, 2015 08:45, Jason Warr <jason at warr.net> wrote: > > On Fri, 2015-08-14 at 16:31 +0100, Michael H wrote: > > Hi Thomas, > > > > > > > Could anybody point me in the right direction for setting the kernel > > > parameter, max_stack_depth, to 10240 for database tuning? > > > > > > I have currently set it by running

On 02/17/2016 07:08 AM, Michael H wrote: > On 17/02/16 13:01, Johnny Hughes wrote: >> I normally just let the daily announce post to this list show what >> is available for updates, but there is a CVE (CVE-2015-7547) that >> needs a bit more attention which will be on today's announce list >> of updates. >> >> We released a new glibc yesterday for

On 02/17/2016 08:10 AM, Michael H wrote: >> The easy answer is yes .. glibc requires so many things to be restarted, >> that is the best bet. Or certainly the easiest. >> >> Note: in CentOS 7, there is also a kernel update which is rated as >> Important .. so you should boot to that anyway: >>

Just a quick addition - On 17/08/15 08:40, Michael H wrote: > Hi Jason, > > On 14/08/15 16:45, Jason Warr wrote: >> On Fri, 2015-08-14 at 16:31 +0100, Michael H wrote: >>> Hi Thomas, >>> >>> >>>> Could anybody point me in the right direction for setting the kernel >>>> parameter, max_stack_depth, to 10240 for database tuning?

On Fri, 2015-08-14 at 16:31 +0100, Michael H wrote: > Hi Thomas, > > > > Could anybody point me in the right direction for setting the kernel > > parameter, max_stack_depth, to 10240 for database tuning? > > > > I have currently set it by running 'ulimit -s 10240' but this does not > > survive a reboot. > > > > > > Thanks for

> The easy answer is yes .. glibc requires so many things to be restarted, > that is the best bet. Or certainly the easiest. > > Note: in CentOS 7, there is also a kernel update which is rated as > Important .. so you should boot to that anyway: > https://lists.centos.org/pipermail/centos-announce/2016-February/021705.html > > Here is a good link to figure out what to

On 08/14/2015 07:19 AM, Michael H wrote: > I have currently set it by running 'ulimit -s 10240' but this does not > survive a reboot. It's already been pointed out that you'll need to modify the init script, but just to make clear why that is the case, I thought it should be pointed out that "ulimit" is a bash built-in command. When you run "ulimit -s

On 17/02/16 14:44, Johnny Hughes wrote: > On 02/17/2016 08:39 AM, Johnny Hughes wrote: >> On 02/17/2016 08:10 AM, Michael H wrote: >>>> The easy answer is yes .. glibc requires so many things to be restarted, >>>> that is the best bet. Or certainly the easiest. >>>> >>>> Note: in CentOS 7, there is also a kernel update which is rated as

On Aug 15, 2015 13:23, Mark Milhollan <mlm at pixelgate.net> wrote: > > On Fri, 14 Aug 2015, Thomas Eriksson wrote: > > >If it's centos 6 stick 'ulimit -s' in the init script > > I suggest putting it in the sysconfig file instead, if such exists. > > Sure, but how many init scripts provide for adding an extra command via sysconfig files? Most of

On 17/02/16 14:32, Michael H wrote: > Hi, re-posting this with a more appropriate subject for my reply; > >> The easy answer is yes .. glibc requires so many things to be restarted, >> that is the best bet. Or certainly the easiest. >> >> Note: in CentOS 7, there is also a kernel update which is rated as >> Important .. so you should boot to that anyway:

Could anybody point me in the right direction for setting the kernel parameter, max_stack_depth, to 10240 for database tuning? I have currently set it by running 'ulimit -s 10240' but this does not survive a reboot. Look at the file /etc/security/limits.conf For documentation, 'man limits.conf' - Thomas

On 08/17/2015 03:34 AM, Michael H wrote: > the [Service] section - > [Service] > LimitSTACK=12288 ... > By the errors I will assume that it should be in the [Service] section. > I couldn't find confirmation of this online... Yes, it belongs in the [Service] section. $ man systemd.exec ... "The execution specific configuration options are configured in the [Service],

Hi, re-posting this with a more appropriate subject for my reply; > The easy answer is yes .. glibc requires so many things to be restarted, > that is the best bet. Or certainly the easiest. > > Note: in CentOS 7, there is also a kernel update which is rated as > Important .. so you should boot to that anyway: >

On 02/17/2016 08:39 AM, Johnny Hughes wrote: > On 02/17/2016 08:10 AM, Michael H wrote: >>> The easy answer is yes .. glibc requires so many things to be restarted, >>> that is the best bet. Or certainly the easiest. >>> >>> Note: in CentOS 7, there is also a kernel update which is rated as >>> Important .. so you should boot to that anyway:

On Fri, 14 Aug 2015, Thomas Eriksson wrote: >If it's centos 6 stick 'ulimit -s' in the init script I suggest putting it in the sysconfig file instead, if such exists. /mark

Am 15.08.2015 um 23:38 schrieb Thomas Eriksson <thomas.eriksson at slac.stanford.edu>: > > On Aug 15, 2015 13:23, Mark Milhollan <mlm at pixelgate.net> wrote: >> >> On Fri, 14 Aug 2015, Thomas Eriksson wrote: >> >>> If it's centos 6 stick 'ulimit -s' in the init script >> >> I suggest putting it in the sysconfig file

Hi all! I'm stuck on something really bizarre that is happening to a product I "own" at work. It's a C program, built on CentOS, runs on CentOs or RHEL, has been in circulation since the early 00's, is in use at hundreds of sites. recently, at multiple customer sites it has started just going away. no core file (yes, ulimit is configured), nothing in any of its (several)