Archiv 16. Mai 2016

Montag, 16. Mai 2016

iPad Pro 9.7″ stirbt mit Error 56 (Update)

Ein Kollege hat sich kürzlich ein iPad Pro 9.7″ gekauft. Das Gerät ist nach einigen Wochen Benutzung abgestürzt, was ihn zu einem Restore gezwungen hat. Leider schlägt diese Prozedur reproduzierbar fehl: iTunes meldet „Error 56“ und der Restore bleibt hängen.

Wer nach „error 56“ „ipad pro“ googlet, findet sowohl auf Twitter als auch auf Web-Sites wie Apple Discussions Hinweise, dass mein Kollege nicht der erste Käufer ist, der sich mit diesem unlösbaren Problem herumplagen muss.

Ich erwarte, dass Apple in den nächsten Tagen (oder Wochen) das Problem offiziell anerkennt. Entweder es lässt sich mit einem Software-Update lösen, oder aber wir haben es hier mit einer fehlerhaften Produktionsserie zu tun (Hardware-Problem).

Nachtrag

Am 20. Mai 2016 war es soweit: Apple comments on ‚Error 56‘, fix on the way for affected iPads.

Wer ein GA besitzt oder in Zürich respektive Basel respektive Genf und Umgebung wohnt vereinbart am einfachsten einen Termin im Apple Store und lässt sich sein gebricktes iPad Pro wie Jean-Claude Frick umtauschen.

Tags: ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Montag, 16. Mai 2016

Wo befinden sich unter Debian die systemd Service-Dateien?

Unzählige dieser Service-Files finden sich in diesem Ordner:

/lib/systemd/system

Quelle: Making your package work with systemd sowie Getting Started With systemd on Debian Jessie

Das Service-File für MySQL habe ich hingegen hier gefunden:

/etc/systemd/system/mysql.service

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Montag, 16. Mai 2016

MariaDB (MySQL) meldet „ERROR 1436 (HY000) at line 574: Thread stack overrun“

Damit die Migration von MySQL nach MariaDB sauber abläuft, ist es wichtig, nach der De-Installation von MySQL und der erfolgreichen Installation von MariaDB folgendes Kommando auszuführen (Anstoss war eine Fehlermeldung in mysql.log):

# mysql_upgrade
...
ERROR 1436 (HY000) at line 574: Thread stack overrun:  5904 bytes used of a 131072 byte stack, and 0 bytes needed.  Use 'mysqld --thread_stack=#' to specify a bigger stack.

Blöd nur, wenn diese Fehlermeldung erscheint. Nach einer kurzen Google-Suche stellte sich heraus, dass mein Konfigurationstuning in /etc/mysql/my.cnf einen Kollateralschaden verursacht hatte. In der Konfigurationsdatei hatte ich nämlich eingestellt:

...
[mysqld]
...
thread_stack		= 128K

Dieser Wert berechnet sich für jedes System basierend auf dessen Eigenschaften und es macht deshalb keinen Sinn, den Wert in my.cnf hartzukodieren, wie der Artikel MySQL error 1436: Thread stack overrun, with simple query aufzeigt.

Das Problem löste sich in Luft auf, indem ich den Eintrag auskommentierte …

#thread_stack		= 128K

… und den Datenbankserver neu startete:

# systemctl restart mysql

Tags: , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Montag, 16. Mai 2016

MariaDB (MySQL) meldet Errcode: 24 „Too many open files“

Vorgestern habe ich auf Grund von Performance-Problemen beim Umstieg auf cacti spine die Datenbank auf meinem Linux-Server ausgetauscht: Statt MySQL kommt nun MariaDB zum Einsatz.

Heute nun wurde ich auf einen Kollateralschaden aufmerksam. Jede Nacht lasse ich ein Script laufen, welches meine MySQL-Datenbanken sperrt (LOCK-ed) und die Datenbankdateien in ein Sicherungsverzeichnis kopiert. Mit tarsnap schreibe ich die Datenbankdateien dann weg in die Cloud und habe so versionierte Datenbankbackups.

Seit dem Wechsel und einigen Anpassungen an der MySQL-Konfiguration (my.cnf) traten bei der Verwendung des Scripts Probleme auf:

...
site_wedding
     /home/mysql/site_wedding.sql
mysqldump: Error: 'Out of resources when opening file '/tmp/#sql_4fde_2.MAD' (Errcode: 24 "Too many open files")' when trying to dump tablespaces
mysqldump: Got error: 23: "Out of resources when opening file './site_wedding/log.MYD' (Errcode: 24 "Too many open files")" when using LOCK TABLES
...

Und auch im mysql.log las ich:

...
May 16 06:30:02 ALPHA mysqld: 160516  6:30:02 [ERROR] Error in accept: Too many open files

Den Fehler behob ich mit folgenden Massnahmen:

Im Zuge des Performance-Tunings der Datenbank (für cacti spine) hatte ich folgende Zeilen in my.cnf eingefügt:

...
[mysqld]
...
open_files_limit	= 80000
...

Beim Starten der Datenbank mittels

# systemctl start mysql

fand sich im MySQL-Log folgender Eintrag:

...
May 16 12:55:45 ALPHA mysqld: 160516 12:55:45 [Warning] Could not increase number of max_open_files to more than 1024 (request: 80162)
...

Offenbar waren 1024 gleichzeitig geöffnete File Handles nicht ausreichend.

Ich nahm deshalb folgende Anpassung an /etc/security/limits.conf vor:

...
mysql hard nofile 102400
mysql soft nofile 102400

Quelle: How to permanently raise ulimit ‚open files‘ and MySQL ‚open_files_limit‘

Ein Neustart von MySQL löste das Problem aber nicht; die Fehlermeldung im Log blieb bestehen (eventuell muss man den Server neu starten, damit diese Limits aktiv werden?).

Ein wenig Recherche fügte dann zu Tage, dass man dem MySQL-Server via der systemd Service-Datei selber eine Maximalzahl an File Handles zuweisen kann.

Unter Debian findet sich die Service-Datei unter /etc/systemd/system/mysql.service, wo ich folgende Zeile einfügte:

...
[Service]
...
LimitNOFILE=infinity

Anschliessend musste ich folgenden Befehl ausführen, damit die Anpassungen von systemd zur Kenntnis genommen werden:

# systemctl stop mysql
Warning: mysql.service changed on disk. Run 'systemctl daemon-reload' to reload units.
# systemctl daemon-reload
# systemctl start mysql

Beim Neustart von MySQL erschien die Fehlermeldung im mysql.log erneut, dieses Mal aber mit einer deutlichen höheren Zahl an gleichzeitig geöffneten Dateien:

...
May 16 13:02:57 ALPHA mysqld: 160516 13:02:57 [Warning] Could not increase number of max_open_files to more than 65536 (request: 80162)
...

Good enough, dachte ich mir. Deshalb entschied ich mich, erneut my.cnf anzupassen:

...
[mysqld]
...
open_files_limit	= 60000
...

Noch einmal den Server neu starten, und gut war es:

# systemctl stop mysql
# systemctl start mysql

Bei der manuellen Ausführung des Scripts lief die Sause anschliessend durch, ohne zu stocken.

Tags: , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen