MySQL nofile, Ubuntu und systemd

systemd verwaltet selber die limits aller Prozesse. Deshalb werden alle normale Parameter in der /etc/mysql/my.cnf, /etc/security/limits.conf oder /etc/sysctl.conf ignoriert.

Wer immer auf diese schwachsinnige Idee gekommen ist, dies nirgendwo vernünftig zu kommentieren: Danke für die Stunden und Tage die hiermit sinnlos verschwendet wurden!

Für MySQL muss folgendes gemacht werden:

Legt das Verzeichnis /etc/systemd/system/mysql.service.d/ an:
mkdir -p /etc/systemd/system/mysql.service.d/

Erstellt die Datei /etc/systemd/system/mysql.service.d/override.conf mit folgenden Inhalt

cat '[Service]
LimitNOFILE=16384' >> /etc/systemd/system/mysql.service.d/override.conf

und startet den Service mysqld neu.

Nice und IO-Nice mit rsync

Eine sehr gute übersichtliche Antwort und Übersicht für rsync und nice Optionen.

Siehe Original: Nice rsync on remote machine – Philippe Gachoud

Taking the –rsyncpath option you have rsync –rsync-path=“ionice -c 3 nice -n 12 rsync“ localDirectory remoteHost:/tmp/
Taking the configuration file option you can change or uncomment in file /etc/default/rsync the RSYNC_NICE=’17‘ value and the RSYNC_IONICE=‘-c3′ value
For both the ionice value will be for hard disc priority

1 -> Real time
2 -> Best effort
3 -> Ildle (when any other process is not using the HD)
for nice value for processor priority

-20 (most favorable to the process)
(default 10) if -n is not specified
19 (least favorable to the process)


rsync -a --delete --rsync-path="ionice -c 3 nice -n 12 rsync" empty/ tmp_voll/

bash-Shell auf einen alten System patchen (Shell-Shock)

Falls Ihr noch ältere Systeme habt, die nicht mehr gepatched werden, dann müsst Ihr die bash manuell patchen und compilieren. Das Gute in diesem Fall ist, dass es eine exzellente Anleitung gibt, die Ihr unter How to Manually Update Bash to Patch Shellshock Bug on Older Fedora-Based Linux Systems findet.

Achtet darauf, dass Ihr die korrekte Bash Version, identisch zur aktuell installierten bash, patched. Versucht kein Upgrade der bash auf eine neuere Version. Bei mir hat es mit einer alten bash 3.2 auch wunderbar geklappt.

mDNSResolver in OS-X

Bei OS-X kann es mit mehreren DNS Servern zu DNS-Problemen führen. Bei mir war es der interne DNS Server der plötzlich „übergangen“ wurde. Es gibt mehrere Beiträge zum Thema, besonders Snow Leopard hatte ein ziemliches DNS-Problem aufgrund einer Umstellung.

Hier nun die wichtigen Beiträge zum Thema:

Die eigentliche Lösung muss über die DNS-Einstellungen des DCHP Servers erfolgen. Es sollte nur ein einziger DNS-Server angegeben werden.

Neustart den mDNSResolvers:

$ sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
$ sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

Anzeige der OS-X DNS Einstellungen:

$ scutil --dns
DNS configuration

resolver #1
search domain[0] : domain-intern.de
search domain[1] : domain-bremen.de
nameserver[0] : 192.168.0.1
if_index : 4 (en0)
flags : Request A records
reach : Reachable,Directly Reachable Address

[...]

Der Linux Kernel ist ein Optimist

Manchmal führt zuviel Optimismus zu Problemen. Dies gilt leider auch für den Linux Kernel in seiner Defaulteinstellung ab Version 2.1.27 bis 2.5.30. Damit der Kernel jede Speicheranfrage per malloc() immer(!) positiv beantworten kann, schickt er seine oom-killer los, um der einen „beliebigen“ Prozess abzuschießen. Als Resultat stürzt u.U. dann der gesamte Rechner ab. Beispielsweise mit folgender Meldung:

sw-engine invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0

Call Trace:
[] out_of_memory+0x8e/0x2f3
[] __alloc_pages+0x27f/0x308
[] __do_page_cache_readahead+0x96/0x17b
[...]

Um das Problem zu lösen, sollte das Verhalten des Kernel angepasst werden, damit nicht mehr Speicher vergeben wird, als vorhanden ist. Dazu sollten in der Datei /etc/sysctl.conf (ab Kernel 2.5.30) folgende Zeilen eingetragen werden:

vm.overcommit_memory = 2
vm.overcommit_ratio = 80

Bei älteren Kerneln (2.1.27 – 2.5.30) sollte die Defaulteinstellung von 1 auf 0 gesetzt werden.

Kontrolle des aktuellen Status: echo '/proc/sys/vm/overcommit_memory' 
    ==> 0 : besser, 1 : overcommit aktiv, der OOM-Killer schlägt zu.
echo '0' > /proc/sys/vm/overcommit_memory

Original-Hinweis findet sich unter How to fix the OOM killer crashes under Linux

Eine genauere Erkärung und Funktionsweise findet man unter The Linux Kernel: Memory – 9.6 Overcommit and OOM

Happy Linuxing … 🙂