(Errcode: 24 - Too many open files)

NeoLeMarc said:
als 32768 setzt.

BTW: Was steht denn im MySQL error log?
l
Click to expand...

Im Error log ist nur der Eintrag vom heutigen Restart.


Code: 
2014-08-19 10:01:29 22219 [Note] /usr/sbin/mysqld: Normal shutdown

2014-08-19 10:01:29 22219 [Note] Giving 3 client threads a chance to die gracefully
2014-08-19 10:01:29 22219 [Note] Event Scheduler: Purging the queue. 0 events
2014-08-19 10:01:29 22219 [Note] Shutting down slave threads
2014-08-19 10:01:31 22219 [Note] Forcefully disconnecting 0 remaining clients
2014-08-19 10:01:31 22219 [Note] Binlog end
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'partition'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'BLACKHOLE'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_SYS_DATAFILES'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_SYS_TABLESPACES'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_SYS_FOREIGN_COLS'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_SYS_FOREIGN'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_SYS_FIELDS'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_SYS_COLUMNS'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_SYS_INDEXES'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_SYS_TABLESTATS'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_SYS_TABLES'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_FT_INDEX_TABLE'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_FT_INDEX_CACHE'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_FT_CONFIG'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_FT_BEING_DELETED'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_FT_DELETED'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_FT_DEFAULT_STOPWORD'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_METRICS'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_BUFFER_POOL_STATS'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_BUFFER_PAGE_LRU'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_BUFFER_PAGE'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_CMP_PER_INDEX_RESET'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_CMP_PER_INDEX'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_CMPMEM_RESET'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_CMPMEM'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_CMP_RESET'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_CMP'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_LOCK_WAITS'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_LOCKS'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'INNODB_TRX'
2014-08-19 10:01:31 22219 [Note] Shutting down plugin 'InnoDB'
2014-08-19 10:01:31 22219 [Note] InnoDB: FTS optimize thread exiting.
2014-08-19 10:01:31 22219 [Note] InnoDB: Starting shutdown...
2014-08-19 10:01:33 22219 [Note] InnoDB: Shutdown completed; log sequence number 40745109742
2014-08-19 10:01:33 22219 [Note] Shutting down plugin 'ARCHIVE'
2014-08-19 10:01:33 22219 [Note] Shutting down plugin 'PERFORMANCE_SCHEMA'
2014-08-19 10:01:33 22219 [Note] Shutting down plugin 'MRG_MYISAM'
2014-08-19 10:01:33 22219 [Note] Shutting down plugin 'MyISAM'
2014-08-19 10:01:33 22219 [Note] Shutting down plugin 'MEMORY'
2014-08-19 10:01:33 22219 [Note] Shutting down plugin 'CSV'
2014-08-19 10:01:33 22219 [Note] Shutting down plugin 'sha256_password'
2014-08-19 10:01:33 22219 [Note] Shutting down plugin 'mysql_old_password'
2014-08-19 10:01:33 22219 [Note] Shutting down plugin 'mysql_native_password'
2014-08-19 10:01:33 22219 [Note] Shutting down plugin 'binlog'
2014-08-19 10:01:33 22219 [Note] /usr/sbin/mysqld: Shutdown complete

140819 10:01:33 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
140819 10:01:34 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2014-08-19 10:01:35 5609 [Warning] Buffered warning: Could not increase number of max_open_files to more than 1024 (request: 32978)

2014-08-19 10:01:35 5609 [Warning] Buffered warning: Changed limits: table_cache: 407 (requested 16384)

2014-08-19 10:01:35 5609 [Warning] You need to use --log-bin to make --binlog-format work.
2014-08-19 10:01:35 5609 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
2014-08-19 10:01:35 5609 [Note] Plugin 'FEDERATED' is disabled.
2014-08-19 10:01:35 5609 [ERROR] Function 'innodb' already exists
2014-08-19 10:01:35 5609 [Warning] Couldn't load plugin named 'innodb' with soname 'ha_innodb.so'.
2014-08-19 10:01:35 5609 [ERROR] Function 'federated' already exists
2014-08-19 10:01:35 5609 [Warning] Couldn't load plugin named 'federated' with soname 'ha_federated.so'.
2014-08-19 10:01:35 5609 [ERROR] Function 'blackhole' already exists
2014-08-19 10:01:35 5609 [Warning] Couldn't load plugin named 'blackhole' with soname 'ha_blackhole.so'.
2014-08-19 10:01:35 5609 [ERROR] Function 'archive' already exists
2014-08-19 10:01:35 5609 [Warning] Couldn't load plugin named 'archive' with soname 'ha_archive.so'.
2014-08-19 10:01:35 5609 [Note] InnoDB: Using atomics to ref count buffer pool pages
2014-08-19 10:01:35 5609 [Note] InnoDB: The InnoDB memory heap is disabled
2014-08-19 10:01:35 5609 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2014-08-19 10:01:35 5609 [Note] InnoDB: Compressed tables use zlib 1.2.7
2014-08-19 10:01:35 5609 [Note] InnoDB: Using Linux native AIO
2014-08-19 10:01:35 5609 [Note] InnoDB: Using CPU crc32 instructions
2014-08-19 10:01:35 5609 [Note] InnoDB: Initializing buffer pool, size = 4.0G
2014-08-19 10:01:35 5609 [Note] InnoDB: Completed initialization of buffer pool
2014-08-19 10:01:35 5609 [Note] InnoDB: Highest supported file format is Barracuda.
2014-08-19 10:01:35 5609 [Note] InnoDB: 128 rollback segment(s) are active.
2014-08-19 10:01:35 5609 [Note] InnoDB: Waiting for purge to start
2014-08-19 10:01:35 5609 [Note] InnoDB: 5.6.19 started; log sequence number 40745109742
/usr/sbin/mysqld: File '/etc/mysql/slow-query.log' not found (Errcode: 13 - Permission denied)
2014-08-19 10:01:35 5609 [ERROR] Could not use /etc/mysql/slow-query.log for logging (error 13). Turning logging off for the whole duration of the MySQL server process. To turn it on again: fix the cause, shutdown the MySQL server and restart it.
2014-08-19 10:01:35 5609 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
2014-08-19 10:01:35 5609 [Note]   - '127.0.0.1' resolves to '127.0.0.1';
2014-08-19 10:01:35 5609 [Note] Server socket created on IP: '127.0.0.1'.
2014-08-19 10:01:35 5609 [Note] Event Scheduler: Loaded 0 events
2014-08-19 10:01:35 5609 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.6.19-1~dotdeb.1-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Debian)
2014-08-19 10:01:35 5609 [Warning] Access denied for user 'root'@'localhost' (using password: NO)
2014-08-19 10:01:35 5609 [Warning] Access denied for user 'root'@'localhost' (using password: NO)

Interessant dürften diese hier sein:

Code: 
2014-08-19 10:01:35 5609 [Warning] Buffered warning: Could not increase number of max_open_files to more than 1024 (request: 32978)

2014-08-19 10:01:35 5609 [Warning] Buffered warning: Changed limits: table_cache: 407 (requested 16384)

Die Frage ist nur, warum er es nicht kann :confused:
 
Hi,

beim nochmaligen Lesen des Threads ist mir aufgefallen, dass deine ulimit-Werte ja gar nicht erhöht wurden. Evtl. liegt es an dem "*" in der ersten Zeile, der funktioniert bei mir auch nicht. Probier mal folgendes in der /etc/security/limits.conf:

Code: 
root soft nofile 102400
root hard nofile 102400
mysql soft nofile 102400
mysql hard nofile 102400

Edit: Gerade beim Lesen der Dokumentation gefunden: "*" wirkt nicht auf den User root:
NOTE: group and wildcard limits are not applied to the root user. To set a limit for the root user, this field must contain the literal username root
 
Wieder was dazu gelernt NeoLeMarc. Habe deinen Vorschlag umgesetzt und siehe da :) :

Code: 
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) 257373
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 102400
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) 257373
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Hab dann den SQL Server neu gestartet und siehe da. Schon werden die Werte übernommen.

Manchmal liegt der Fehler wirklich im Detail. Mein Ansatz war schon richtig über die Parameter zu gehen nur das die für Root nicht gelten, habe ich nicht gewusst.

Obwohl in der my.cnf ein anderer Wert definiert wird was die open Files angeht, scheint der auch immer die Werte des Betriebssystem zu nehmen und die aus der my.cnf zu ignorieren.

Danke noch mal.
 
Habt ihr das übersehen? Dass für root auch wirklich root angegeben werden muss, steht doch unübersehbar drin in der /etc/security/limits.conf:
"To apply a limit to the root user, <domain> must be the literal username root."

cat /etc/security/limits.conf
# /etc/security/limits.conf
#
#Each line describes a limit for a user in the form:
#
#<domain> <type> <item> <value>
#
#Where:
#<domain> can be:
# - an user name
# - a group name, with @group syntax
# - the wildcard *, for default entry
# - the wildcard %, can be also used with %group syntax,
# for maxlogin limit
# - NOTE: group and wildcard limits are not applied to root.
# To apply a limit to the root user, <domain> must be
# the literal username root.
Click to expand...
 
Hi Gwen,

GwenDragon said:
Habt ihr das übersehen? Dass für root auch wirklich root angegeben werden muss, steht doch unübersehbar drin in der /etc/security/limits.conf:
"To apply a limit to the root user, <domain> must be the literal username root."
Click to expand...

das ist ein Debian spezifischer Patch (Vgl. Debian#62448 resp. Ubuntu#65244), er dem 15. April 2000 in libpam-modules eingearbeitet wurde. Unter RHEL 6 sieht die Datei z.B. so aus:

Code: 
#Where:
#<domain> can be:
#        - an user name
#        - a group name, with @group syntax
#        - the wildcard *, for default entry
#        - the wildcard %, can be also used with %group syntax,
#                 for maxlogin limit
#
#<type> can have the two values:
#        - "soft" for enforcing the soft limits
#        - "hard" for enforcing hard limits

Von daher: Ja, hab ich tatsächlich übersehen. ;-)
 
Bleibt noch die Frage offen, warum bei dem System root überhaupt limitiert ist.
Ich kann mich jedenfalls nicht daran erinnern jemals ein System mit limitiertem root gesehen zu haben (zumindest nicht ohne ganz bewusstem Eingriff von root selbst).

Nächste Frage: Welche Limits gelten, wenn PAM komplett vom System entsorgt wird (was auf Servern Sinn macht)?
 
Hi,

das Default value kommt vom Kernel und hängt von der Version ab:

http://git.kernel.org/cgit/linux/ke.../?id=0ac1ee0bfec2a4ad118f907ce586d0dfd8db7641

Daher ist es bei Debian stable aktuell auch bei 4096 und bei unstable bei 65536. Von daher ändert sich daran auch nichts, wenn Du PAM entfernst.

Und PAM entfernen wird... spannend. Unter Gentoo oder Archlinux dürfte das deutlich einfacher als unter Debian sein. Aber irgendwie halte ich das für keine gute Idee. ;-)
 
Ja die Kerneldefaults sind böse knapp (bei anderen UNIXartigen Systemen gar noch knapper), sollten aber spätestens durch login/shell mit sinnvollen Defaults überschrieben werden. Warum diese sinnvollen Defaults auf dem System von Unifex nicht existieren, das ist die interessante Frage.


Gentoo ohne PAM hatte ich über Jahre problemlos produktiv.
 
Ich glaube nicht, dass Unifex da irgend etwas falsch gemacht hat. Auf den Debian-Stable Kisten, die ich spontan gefunden habe, scheint das genau so zu sein. Auf unstable ist es signifikant höher (65k).
IIRC sind standardmäßig nur interaktive Shells limitiert. Vermutlich lag das Problem einfach daran, dass bei einem händischen Ausführen von /etc/init.d/mysqld restart "aus Versehen" die Limits der Shells an den Daemon vererbt wurden - beim Reboot hätte es sich evtl. anders Verhalten.

Was stört Dich eigentlich an PAM?
 
Ich konnte für die üblichen 0815-RootServer noch kein einziges Szenario entdecken in dem PAM sinnvoll eingesetzt werden könnte. Im Gegenteil, bisher waren alle Lösungen ohne PAM erheblich unproblematischer umsetzbar und es gab dadurch auch weniger ungewollte Wechselwirkungen.

Bestes und einfachstes Beispiel dürfte wohl OpenSSH sein. Dort bereitet PAM deutlich mehr Probleme als es lösen kann.


Gegenfrage: Nenne mir mal ein Szenario wo PAM sinnvoll und besser ist als die Boardmittel der Anwendung?
 
Apps die LDAP nutzen, können dies üblicherweise nativ sprechen und benötigen dafür kein PAM.
Kerberos lässt sich besser per GSSAPI umsetzen und ist so auch recommended: http://web.mit.edu/kerberos/krb5-devel/doc/appdev/gssapi.html
2-Faktor-Auth und Co lassen sich ebenfalls nativ viel besser als mittels PAM umsetzen.


Slackware wurde beispielsweise noch nie mit PAM-Support released und trotzdem funktionieren dort LDAP, Kerberos und was sonst so per PAM verbastelt wird.
Beispiel für Krb5: http://arktur.shuttle.de/CD/Testpakete/Kerberos/krb5.html
 
Wenn ich es mir Recht überlege, reden die meisten meiner Applikationen (Samba, Mailserver, Tomcat, Confluence... etc.) auch schon direkt mit dem LDAP und nicht mit PAM. Ok, Du hast mich überzeugt. :-)

Allerdings glaube ich weiterhin, dass es fummelig wird, PAM aus einem existierenden Debian komplett auszubauen, weil da die ganzen Pakete gegen libpam.so gelinkt sind.
 
NeoLeMarc said:
Ich glaube nicht, dass Unifex da irgend etwas falsch gemacht hat
Click to expand...


Nönö, ich habe da nix falsch gemacht. Das ist so Standard auf meinen Debian Kisten und in der Limits steht auch bei mir kein explizierter Hinweis, dass die Einstellungen für Root nicht gelten sollen.

Darum war ich umso überraschter über den Hinweis, denn in keinem Tutorial war darauf ein Hinweis vergeben.
 
Unifex said:
Darum war ich umso überraschter über den Hinweis, denn in keinem Tutorial war darauf ein Hinweis vergeben.
Click to expand...

Wie gesagt, der Fehler war ziemlich fies. Normalerweise zieht limits.conf für Root überhaupt nicht. Außer auf Debian, da gibt es einen Patch, der es explizit mal für root aktiviert hat. Und die Limits gelten normalerweise auch nicht für Daemons, wenn diese von init gestartet werden, weil da PAM und damit auch pam_limits.so nicht beteiligt ist.
Ich vermute, dass die in Deinem Fall deswegen gezogen haben, weil Du als User Root von einer interaktiven Shell mit angewendeten ulimits das init-Skript direkt ausgeführt hast und Deine ulimits dann von dem Shell-Prozess an den mysqld Prozess vererbt wurden. Und wahrscheinlich haben die Entwickler es versäumt, in mysqld setrlimit() aufzurufen, um die limits wieder zurück zu setzen. Aber wie gesagt, das ist nur eine Vermutung, ich kenne den Quellcode von mysqld nicht im Detail.

Interessant wäre, was nach einem Reboot passiert. Es kann sein, dass dann wieder das Kernel-Default für den mysqld gilt. In dem Fall müsstest Du Deine Werte noch in /etc/sysctl.conf nachpflegen.
 
NeoLeMarc said:
Allerdings glaube ich weiterhin, dass es fummelig wird, PAM aus einem existierenden Debian komplett auszubauen, weil da die ganzen Pakete gegen libpam.so gelinkt sind.
Click to expand...

Richtig, aber dafür gibt es ja ganz einfache Lösungen die gleichzeitig auch fast alle anderen Probleme von Debian auf einen Schlag beheben: Slackware oder source-based Distros ala Gentoo ;)
 
NeoLeMarc said:
Warum kommt mir jetzt der legendäre "Now you have two problems"-Thread[1] von Jamie Zawinski et.al. in den Sinn? ;-)
Click to expand...
Keine Ahnung, vielleicht hast Du ja eine andere Lösung mit anderen Problemen ;)



Könnte das Problem von Unifex/Debian an dash liegen?
@Unifex Welches ist Deine Standardshell (/bin/sh) beziehungsweise welche Shell verwenden bei Dir init und root?
 
Dieses Problem scheint es nur bei MySQL 5.6 zu geben.

Ich habe nun ein paar Stunden damit verbracht, dies auf einem Entwicklungsserver zu fixen. Leider hat es mir nicht den gewünschten Erfolg gebracht, so dass ich letzten Endes MySQL 5.5 wieder installiert habe.

Ich sehe keine wirklichen Vorteile der Verwendung von 5.6 und mir persönlich war das ein zu großes "Rumgehacke" im System.

Zudem habe ich folgendes festgestellt: Habe ich dem User root ein höheres open_files_limit zugewiesen, so galt dies ausschließlich mit einem direkten Login per root, also nicht einmal per Wechsel durch "su". Bei einem Systemboot wird das open_files_limit wohl erst NACH dem Start von MySQL gesetzt. Jedenfalls musste ich zuerst mit dem root-user den MySQL Dienst neu starten, dass das open_files_limit neu eingelesen wurde. Ich nehme an, irgendwo in einem Startup-Skript von MySQL hätte man dies umschreiben können. Zumindest in meiner my.conf hatte es keinerlei Auswirkungen.

Mein persönliches Fazit ist also, dass MySQL 5.6 für Debian noch nicht wirklich taugt, wenn man es nicht zwingend braucht. Auf einem Entwicklungssystem kann man damit vielleicht etwas rumspielen. Auf Prod-Servern würde ich jedoch die Finger davon lassen...
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top