[Solved] Open Files Limit und LDAP

[dank]

Hi,

ich habe hier einen LDAP-Server laufen und ein paar Clients (> 100). Nach einiger Zeit antworted der Server nicht mehr, weil angeblich zu viele Dateien göffnet sind. Netstat mein etwas von knapp über 1024 Verbindungen. Das klingt stark danach, dass die Debian limits nicht passen. Nur habe ich die nofiles limits bereist vor einiger Zeit auf 32000 (soft) und 64000(hard) hochgesetzt.

Code: Alles auswählen

tail -n3 /etc/security/limits.conf 
*		soft	nofile		32000
*		hard	nofile		64000
# End of file

Ulimit zeigt auch die richtigen Limits an

Code: Alles auswählen

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) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 32000
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Kann mir vielleicht jemand sagen, was ich falsch mache? Warum greifen meine neuen Limits nicht?

Gruß

[Six]

GNU/Linux kennt außer den per-process limts (das was du uns zeigst) auch noch ein kernel limit.

Code: Alles auswählen

cat /proc/sys/fs/file-max

gibt das aus. Es würde mich allerdings wundern, wenn es das wäre, normalerweise liegt das im sechs- bis siebenstelligen Bereich.

[dank]

Danke für die Antwort.

Auf dem Server läuft ein Debian Stable:

Code: Alles auswählen

# cat /proc/sys/fs/file-max
101032

Ein cat /proc/sys/fs/file-nr meint

1024 0 101032

1024 für reservierte Dateihandle und keine freien? Kann das sein? Sieht zumindest verdächtig aus.

Wie kann ich die anpassen?

Gruß

[Six]

Ein cat /proc/sys/fs/file-nr meint

1024 0 101032

1024 für reservierte Dateihandle und keine freien? Kann das sein? Sieht zumindest verdächtig aus.

Wie kann ich die anpassen?

Laut Kerneldoku wird seit Linux 2.6 der "allocated but free" Wert immer als 0 ausgegeben. Mir ist im Augenblick nur klar, dass das eine Statistik ist und man in file-nr nichts ändern kann. Warum dein System bei 1024 open file handles dicht macht, weiß ich entsprechend nicht. Das ist aber spannend, mal wühlen.

[Six]

Gerade in http://www.mjmwired.net/kernel/Document ... ctl/fs.txt gefunden in:

110 nr_open:
111
112 This denotes the maximum number of file-handles a process can
113 allocate. Default value is 1024*1024 (1048576) which should be
114 enough for most machines. Actual limit depends on RLIMIT_NOFILE
115 resource limit.

Sieht so aus, als wäre das bei dir auf 32^2, aber warum?

[dank]

Gerade eben ist es wieder passiert. LDAP mag nicht mehr. Alle clients reagieren nicht. Hier mal mein Syslog:

Code: Alles auswählen

Jun 18 23:20:23 server slapd[27218]: warning: cannot open /etc/hosts.allow: Too many open files
Jun 18 23:20:23 server slapd[27218]: warning: cannot open /etc/hosts.deny: Too many open files

Un ein paar weitere Infos.

Code: Alles auswählen

# lsof | grep slapd | wc -l
1066
# cat /proc/sys/fs/file-nr 
1728	0	400652

Ich bin ein wenig am verzweifeln.Ich nicht weiß, was ich noch machen kann (außer einem stupiden cron der in der Nacht alle connections tötet).

Gruß

[uname]

Eigentlich habe ich keine Ahnung. Aber du könntest noch mal schauen ob du was in

Code: Alles auswählen

/etc/default/slapd

ändern kannst.

[dank]

Eigentlich habe ich keine Ahnung. Aber du könntest noch mal schauen ob du was in

Code: Alles auswählen

/etc/default/slapd

ändern kannst.

Leider nix zu den Filehandle.

Aber: Aktuell läuft der Server als Nutzer openldap. Ich überlege, dass ganze als root laufen zu lassen. Nicht schön, aber vielleicht klappt es ja.

Gruß

[uname]

Aktuell läuft der Server als Nutzer openldap

Aha. Und wie sehen bei dem Benutzer die Limits im Detail aus? Kann es daran liegen?

[dank]

Aktuell läuft der Server als Nutzer openldap

Aha. Und wie sehen bei dem Benutzer die Limits im Detail aus? Kann es daran liegen?

Gute frage. Wie kommt man den da ran?

Code: Alles auswählen

su openldap

geht nicht.

Wie auch immer. Die Limits wurden von mir ja bereits in /etc/security/limits.conf allgemein so hoch gesetzt. Ein

#cat /proc/`pidof slapd`/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes unlimited unlimited processes
Max open files 32000 64000 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 16382 16382 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us

Zeigt auch die entsprechenden Limits für den Prozess selber korrekt an.

[uname]

Kann es noch eine Beschränkung im Quellecode (bzw. Kompilierung) sein? Leider konnte ich bei der Durchsicht des Quellcodes nicht die Fehlermeldung finden, um Rückschlüsse über eine evtl. Variable zu erhalten.

[dank]

Kann es noch eine Beschränkung im Quellecode (bzw. Kompilierung) sein? Leider konnte ich bei der Durchsicht des Quellcodes nicht die Fehlermeldung finden, um Rückschlüsse über eine evtl. Variable zu erhalten.

Ich hoffe nicht. Ist ein Original Debian Paket. Und ich wollte es eigentlich nicht neu bauen müssen. Ist ein Produktivsystem mit ner Menge Clients...
Passende OpenLDAP Foreneinträge dazu verweisen auch immer auf ulimit. Z.B. http://www.openldap.org/lists/openldap- ... 00037.html

[uname]

Vielleicht als Übergangslösung. Keine Ahnung ob die Idee für Debian ist und funktioniert.

> We have had the same problem but we have solved this problem change the
variable idletimeout
> in the slapd.conf file. In default its valor is 0 and we have changed to 30, and now this error
> "too many open files" dosen't take place.

http://www.sunmanagers.org/pipermail/su ... 06226.html

[dank]

Vielleicht als Übergangslösung. Keine Ahnung ob die Idee für Debian ist und funktioniert.

> We have had the same problem but we have solved this problem change the
variable idletimeout
> in the slapd.conf file. In default its valor is 0 and we have changed to 30, and now this error
> "too many open files" dosen't take place.

http://www.sunmanagers.org/pipermail/su ... 06226.html

Der Parameter war bei mir schon so gesetzt:

Code: Alles auswählen

idle-timeout            30
timelimit               30
network-timeout         30

[Six]

Kannst du bitte mal die Dateien /etc/security/limits.conf (nicht die ulimits-Ausgabe) und /etc/pam.d/systemauth posten.

[dank]

Kannst du bitte mal die Dateien /etc/security/limits.conf (nicht die ulimits-Ausgabe) und /etc/pam.d/systemauth posten.

Code: Alles auswählen

grep -v "^#" /etc/security/limits.conf 
*		soft	nofile		32000
*		hard	nofile		64000

/etc/pam.d/systemauth gibt es nicht.

[Six]

Poste mal ein paar kontextuelle Angaben: OpenLDAP Version, Debian Version, 64bit ja/nein und poste mal deine slapd.conf nach nopaste.

[dank]

Code: Alles auswählen

dpkg -l | grep slapd
ii  slapd                              2.4.23-7.2                   OpenLDAP server (slapd)

Code: Alles auswählen

cat /etc/debian_version 
6.0.5

Das ganze ist 32 bit.

Code: Alles auswählen

# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.

#######################################################################
# Global Directives:

# Schema and objectClass definitions
include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema

# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile         /var/run/slapd/slapd.pid

# List of arguments that were passed to the server
argsfile        /var/run/slapd/slapd.args

# Read slapd.conf(5) for possible values
loglevel        none
# loglevel        256

# Where the dynamically loaded modules are stored
modulepath	/usr/lib/ldap
moduleload	back_hdb
moduleload	back_ldap
moduleload	rwm

# The maximum number of entries that is returned for a search operation
sizelimit 100

# The tool-threads parameter sets the actual amount of cpu's that is used
# for indexing.
tool-threads 1

# verwendete backends
backend		hdb
backend		ldap

# lokale datenbank
database        hdb

suffix          "ou=ldapserver,ou=user,o=myown"
#DN des superusers
rootdn          "cn=admin,ou=ldapserver,ou=user,o=myown"
rootpw		{SSHA}mykey
# verschachtelung:
subordinate
# datenverzeichnis:
directory       "/var/lib/ldap"
#tuning:
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500
checkpoint      512 30

# index           objectClass,uid,cn,uidnumber eq
index           uid,uidNumber,gidNumber,member,memberUid,uniqueMember,objectClass,cn eq

#braucht man wahrscheinlich nicht, wenn man nicht repliziert:
lastmod         off

# standard-ACLs:
access to attrs=userPassword,shadowLastChange
        by anonymous auth
        by self write
        by * none

access to dn.base="" by * read

access to *
        by * read

####################
# proxy config

database		ldap
suffix			"ou=user,o=remote"
uri			"ldaps://remote-ip/"
idassert-bind 		
	bindmethod=simple 
	binddn=cn=proxy-remote,ou=service,o=remote
	credentials=myremotepw
idassert-authzFrom	"dn.exact:cn=localproxy,ou=ldapserver,ou=user,o=myown" 

idle-timeout 		30
timelimit		30
network-timeout		30
norefs 			yes
protocol-version 	3
use-temporary-conn 	yes

TLSCertificateFile	/etc/ssl/certs/ca-cert.pem
TLSCertificateKeyFile	/etc/ssl/private/ca-key.pem
TLSVerifyClient never

Gruß

[Six]

Wenn es /etc/pam.d/systemauth nicht gibt, dann gucke mal in /etc/pam.d/other und füge folgende Zeile ein:

Code: Alles auswählen

session    required   pam_limits.so

Es kann gut sein, dass das bereits in einem anderen File steht. Versuch's trotzdem. Danach slapd neu starten oder evtl. sogar rebooten.

PS: Laut Doku lautet der Parameter in slapd.conf nicht "idle-timeout", sondern "idletimeout".

[dank]

Ist eingebaut. Ich teste es mal. Feedback dauert bis zum nächsten Blocken .

Allerdings: Sollte nicht jeder user von Haus aus die Limits bekommen, auch wenn kein Login erfolgt?

[dank]

Ob das ursprünglich mit dem Thread gestartete Problem des Limits durch den Pam-Eintrag gelöst wurde kann ich leider nicht sagen.

Dank deines Hinweises zu "idletimeout" werden Verbindungen nun aber sauber(er) geschlossen, so dass ich so schnell nicht mehr in die 1024er Grenze rein renne.

Ein großes Danke für den Hinweis

[Six]

Naja, immerhin

Ich habe im Rahmen dieses Threads eine Menge Unterlagen durchgestöbert und in einer alten RHCE Folie wurde erwähnt, dass es in Linux eine hardcodierte Limitierung namens FD_SETSIZE gibt, die 1024 beträgt. Diese greift wohl bei Zugriff über select() auf file handles, was OpenLDAP wenigstens bis Version 2.2 benutzt haben muss, was der FDS (heute 389) nicht macht --- der benutzt poll() --- und natürlich viel besser ist Was das letzlich bedeutet, weiß ich nicht, ich bin kein Kernelhacker und noch nicht mal mittelmäßig in C.

Ob sich das in OpenLDAP 2.4 geändert hat, weiß ich auch nicht, aber vielleicht liegt da der Hase im Pfeffer. Offizielle Lösung des Problems ist übrigens: "keep idletimeout =< 14400" (was 4h wären. Mit 30 Sekunden bist du natürlich deutlich drunter).

[dank]

Wow. Dann würde ich mal sagen, dass das andere Problem damit auch geklärt ist.

Danke noch mal an alle für die Hilfe und Six im besonderen.
Gruß