CentOS6 probleempje met ulimit

[bami82]

Beste WHT'ers,

Ik loop tegen een probleempje aan met het testen van wat software onder CentOS6 64 bits. Het lijkt erop dat hij door de max user processes of max open files heengaat maar eigenlijk kan dat niet.

Het probleem is dat ik na het starten van wat software (die prima werkte op centos5.6 32 bits) als een bepaalde user niet meer kan inloggen als die user. Als ik als root via su probeer te switchen naar die user krijg ik:

# su - sfe
su: cannot set user id: Resource temporarily unavailable

Wellicht weet iemand wat hier fout gaat en hoe ik dit op kan lossen?

Mijn instellingen zijn als volgt

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 62760
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 65536
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

#ps -eLf | grep <username> | wc -l
1187

#lsof | grep <username> | wc -l 
2616

# cat /etc/security/limits.conf    <het stukje dat ik heb toegevoegd>
*               soft    nofile          65536
*               hard    nofile          65536
*               soft    nproc           unlimited
*               hard    nproc           unlimited

[redbeenl]

Staat selinux misschien nog op enforcing:
# cat /etc/sysconfig/selinux

[bami82]

Staat selinux misschien nog op enforcing:
# cat /etc/sysconfig/selinux

Ik heb selinux voor de zekerheid gedisabled. Helaas maakt dat geen verschil.

[bami82]

Als ik su <username> doe krijg ik bash: fork: retry: Resource temporarily unavailable dus ik loop duidelijk tegen een limiet aan, maar ik snap niet waar dat zit. Iemand anders nog ideeen?

[crossplatform]

Ik heb selinux voor de zekerheid gedisabled. Helaas maakt dat geen verschil.

Volgens mij moet je rebooten om selinux te disablen. Is dat ook gebeurt?
Zie je iets in de logfiles terug?

[bami82]

Systeem is gereboot, selinux staat uit. Logfiles staat verder niks in.

[root@tst4 log]# sestatus
SELinux status:                 disabled

[maxnet]

Naast de PAM limits, zijn er ook een aantal limieten die voor het hele systeem gelden, en welke je deels in /proc/sys kan instellen.
Vroeger was het ook zo dat een individuele (niet root) gebruiker maximaal de helft van de system-wide limiet mocht gebruiken, maar weet niet of dat nog steeds zo is.

[crossplatform]

Wat gebeurt er als je een gebruiker de shell /bin/sh geef?
Het kan zijn dat er een fout zit in je /etc/profile, .profile, .bashrc, oid....

[bami82]

Wat gebeurt er als je een gebruiker de shell /bin/sh geef?
Het kan zijn dat er een fout zit in je /etc/profile, .profile, .bashrc, oid....

Dat gaat gewoona allemaal goed. Weet ook inmiddels welk process het veroorzaakt, als ik het process vervolgens als root start werkt alles perfect maar dat is niet helemaal gewenst.

[crossplatform]

Dat gaat gewoona allemaal goed. Weet ook inmiddels welk process het veroorzaakt, als ik het process vervolgens als root start werkt alles perfect maar dat is niet helemaal gewenst.

En welk proces is dat?

Is misschien wel wenselijk als je wilt dat wij je helpen tot een oplossing te komen

[bami82]

En welk proces is dat?

Is misschien wel wenselijk als je wilt dat wij je helpen tot een oplossing te komen

Tja, zelf geschreven software die het prima deed op Centos 5.6 32 bit en nu dus gerecompiled op CentOS 6 64 bits niet meer

[crossplatform]

Tja, zelf geschreven software die het prima deed op Centos 5.6 32 bit en nu dus gerecompiled op CentOS 6 64 bits niet meer

OK...! back to the drawingboard?

[visser]

Tja, zelf geschreven software die het prima deed op Centos 5.6 32 bit en nu dus gerecompiled op CentOS 6 64 bits niet meer

Met de foutmelding die je noemt (fork: retry: Resource temporarily unavailable ) is bijna zeker dat je proces enorm vaak probeert te forken.
Je hebt zelden of nooit een 'normaal' proces wat terecht zo vaak moet forken dat je tegen zo'n limiet aanloopt, dus per saldo heb je een fork bommetje nu.

Als root werkt het wel schrijf je, nu heeft root een hogere limiet, maar ik denk dat het feitelijke probleem iets anders is.
Ik denk dat je programma probeert een file te creeeren, of een resource te locken wat niet lukt, en dat niet goed afhandelt (en dan enorm vaak forked).
Als root zal dat dan wel lukken, vandaar dat het 'normaal' werkt.

Ik zou dus zoeken in je programma wat het probeert te doen bij start. Je hebt kans dat als je het start onder strace je al ziet wat er gebeurt.
Maar desondanks is dit gedrag natuurlijk wel een bug.

[bami82]

Met de foutmelding die je noemt (fork: retry: Resource temporarily unavailable ) is bijna zeker dat je proces enorm vaak probeert te forken.
Je hebt zelden of nooit een 'normaal' proces wat terecht zo vaak moet forken dat je tegen zo'n limiet aanloopt, dus per saldo heb je een fork bommetje nu.

Als root werkt het wel schrijf je, nu heeft root een hogere limiet, maar ik denk dat het feitelijke probleem iets anders is.
Ik denk dat je programma probeert een file te creeeren, of een resource te locken wat niet lukt, en dat niet goed afhandelt (en dan enorm vaak forked).
Als root zal dat dan wel lukken, vandaar dat het 'normaal' werkt.

Ik zou dus zoeken in je programma wat het probeert te doen bij start. Je hebt kans dat als je het start onder strace je al ziet wat er gebeurt.
Maar desondanks is dit gedrag natuurlijk wel een bug.

Tja het is maar hoe je het bekijkt. Het process mag zeker 2000x forken en dat moet geen probleem zijn. Als ik op het moment van het probleem kijk zijn er maar 1187 processes open, dus een fork bom zou ik het niet willen noemen. Het is nogal complexe software die een telefonie kaart aanstuurd. Dit werkte dus zonder problemen op CentOS 5.6 (32 bits) en op Solaris 10 (Sparc). Begrijp dus niet waarom CentOS 6 het niet accepteerd.

[visser]

Tja het is maar hoe je het bekijkt. Het process mag zeker 2000x forken en dat moet geen probleem zijn. Als ik op het moment van het probleem kijk zijn er maar 1187 processes open, dus een fork bom zou ik het niet willen noemen. Het is nogal complexe software die een telefonie kaart aanstuurd. Dit werkte dus zonder problemen op CentOS 5.6 (32 bits) en op Solaris 10 (Sparc). Begrijp dus niet waarom CentOS 6 het niet accepteerd.

Ik blijf het een fors hoog aantal processen vinden. Linux kan enorm snel forken, dus of je moment-opname van het aantal open processen nu iets zegt dat je daarmee onder de limiet blijft betwijfel ik.
Het zou nog best kunnen dat daarvoor hij er nog een paar honderd meer had.

Hoeveel processen draaien er bij de centos 5 en Solaris 10 versies ?