Andrew, could you pls fix them in the ansible script, that way the configuration is re-producible? https://github.com/apache/toolchain/
Let me know if you need help with fixing through ansible.. -giri On Wed, Oct 1, 2014 at 3:57 PM, Andrew Bayer <andrew.ba...@gmail.com> wrote: > Tweaking all the slaves to go offline when idle - I'll switch 'em back > to normal "always on" once they've all had a chance to > disconnect/reconnect. > > A. > > On Wed, Oct 1, 2014 at 3:50 PM, Rajiv Chittajallu <raj...@yahoo-inc.com> > wrote: > > /etc/security/limits.conf is only used by pam_sessions. Limits are set > for > > processes, based on this configs, only if an session is initiated via a > > process (login/sudo/ssh etc) that uses PAM. Processes started by upstart, > > or manually (including root) would only inherit parent limits, what ever > > that is, independent of user id. > > > > > > Root (or any caller with CAP_SYS_RESOURCE privs) can update/set limits > for > > current for spawned children. These doesn¹t read > /etc/security/limits.conf > > either. > > > > Current issue was in PAM being disabled in standard ASF configs for SSHD. > > So sessions started via sshd, has default limits, inherited from sshd > > process. This has been fixed now. Once jenkins slaves are restarted (via > > new ssh session), they should get appropriate limits per limits.conf. > > > > Host reboot is not required to change limits for a process. > > > > -rajive > > > > On 10/1/14, 3:21 PM, "Andrew Bayer" <andrew.ba...@gmail.com> wrote: > > > >>Root seems to still have that set to 1024 - might be that the way that > >>Jenkins is ssh'ing it's inheriting the limits from root or something? > >> > >>On Wed, Oct 1, 2014 at 3:14 PM, Giridharan Kesavan > >><gkesa...@hortonworks.com> wrote: > >>> It¹s set permanently in the limits.conf. But somehow jenkins its not > >>> picking it up > >>> , even after a reboot. > >>> > >>> > >>> > >>> jenkins@asf905:~$ hostname -fasf905.gq1.ygridcore.net > >>> jenkins@asf905:~$ ulimit -n > >>> 60000 > >>> > >>> jenkins@asf905:~$ cat /etc/security/limits.conf | grep nofile > >>> # - nofile - max number of open files > >>> jenkins soft nofile 60000 > >>> jenkins hard nofile 60000 > >>> > >>> > >>> > >>> -giri > >>> > >>> On Wed, Oct 1, 2014 at 2:10 PM, David Nalley <ke4...@apache.org> > wrote: > >>> > >>>> Rajiv: > >>>> > >>>> Can you take a look at BUILDS-17 - we don't seem to be able to change > >>>> ulimit on a number of machines at Yahoo!. Or rather, it's not > >>>> preserved past reboot it seems. > >>>> > >>>> https://issues.apache.org/jira/browse/BUILDS-17 > >>>> > >>>> Thanks, > >>>> > >>>> --David > >>>> > >>> > >>> -- > >>> CONFIDENTIALITY NOTICE > >>> NOTICE: This message is intended for the use of the individual or > >>>entity to > >>> which it is addressed and may contain information that is confidential, > >>> privileged and exempt from disclosure under applicable law. If the > >>>reader > >>> of this message is not the intended recipient, you are hereby notified > >>>that > >>> any printing, copying, dissemination, distribution, disclosure or > >>> forwarding of this communication is strictly prohibited. If you have > >>> received this communication in error, please contact the sender > >>>immediately > >>> and delete it from your system. Thank You. > > > -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
