Neues in der Kategorie systemd

Volles Rohr 2016

Moinsen bin 2016 noch sehr sehr aktiv.

Erst mal fuer alle, welche es verpasst haben. In der aktuellen iX (2016/16) habe ich einen Artikel mitverbrochen. Ich habe ueber Docker Swarm Mode und Kubernetes schreiben duerfen.

Zudem gibt es wieder ungesund viele Vortraege:

Ein aktuelles systemd (z.B. das in Ubuntu 16.04) instrumentiert via TasksMax mittlerweile die pid Cgroups. Quasi ein ulimit -u via Cgroups.

Folgender Commit ändert die Beschränkt die Prozesse/Thread aller Services.

commit 9ded9cd14cc03c67291b10a5c42ce5094ba0912f
Author: Lennart Poettering <lennart@poettering.net>
Date:   Fri Nov 13 19:28:32 2015 +0100

    core: enable TasksMax= for all services by default, and set it to 512

    Also, enable TasksAccounting= for all services by default, too.

    See:

    http://lists.freedesktop.org/archives/systemd-devel/2015-November/035006.html

Damit haben wir leider:

$ systemctl show -p TasksMax docker
TasksMax=512

$ systemctl show -p TasksMax mysql
TasksMax=512

Damit stoßen schon bei mittelmäßiger Belastung an die Grenzen /o\ Also nicht wundern, wenn nach einem Upgarde auf z.B. Ubuntu 16.04 nichts mehr skaliert :)

Folgendes stellt das vorherige Verhalten wieder her.

TasksMax=infinity

Dieser darf jetzt gerne angepasst werden;)

Viel Spaß

Erkan \o/

Update 1: Zumindest in Debian/Ubuntu wird in einem Update wieder TaskMax=infinity sein

Update 2: Ab Version 230 gibt es einen neuen Default: KillUserProcesses=yes. Einfach nachlesen und heulen :)

Moinsen,

Ich habe feststellen dürfen, dass ich nächsten Monat noch zwei Kurse im Linuxhotel gebe: 

Für alle, die wissen wollen welche damalige Zukunft heute Gegenwart für Linuxadmins ist:
Linux Admin Update vom 18.-19.04 (Cgroups/Namespaces/Capabilities/systemd)

Und für alle, die auch mal OS-Container machen wollen. Ich denke wir werden auch noch
LXD machen :) 
LXC LinuxContainers vom 20.-21.04. Geht auch beides in einem Rutsch :)

Viel Spaß
Erkan



Docker in der iX

| Keine Kommentare | Keine TrackBacks
Moinsen FYI:
In der aktuellen iX (3/2016) und in der Beilage gibt es je einen Artikel von meinereiner.
Docker Tuturial Part 1
Container werden erwachsen

\o/

Moin,

Ich habe einen Artikel zu systemd-nspawn in der iX verfassen dürfen. 
Imho ein guter Einstieg, der auch klar macht was das Alleinstellungsmerkmal von systemd-nspawn ist. (Aber auch wo es nervt :)

Viel Spaß
Erkan


Ahoi auf der CommitterConf in Essen (09.-11.11) gibt es zwei Vorträge von mir:

Das steigt im Unperfekthaus. Auch eine nette Location :)

In der Manpage von systemd-nspawn wird gezeigt wie ein Debian gebootstrapt wird und mit systemd-nspawn gestartet.
Das funktioniert auch sehr schön. 
Der Witz von systemd-nspawn ist aber die Integration in systemd. 
systemd-nspawn von Debian/Ubuntu hat die dbus nur als Recommendation. Damit kann systemd@Host nicht mit systemd@Container kommunizieren.
Sprich wir brauchen im Container dbus.

Ein: debootstrap --arch amd64 --include dbus ....
ist eine Möglichkeit ein Debian/Ubuntu zu Bootstrappen, welches via systemd/systemctl@Host auch genutzt werden kann. 

Viel Spaß
Erkan :)
 

systemd ist auf dem Vormarsch. Auch MySQLer werden sich damit arangieren müssen.

Hier ein kleines Beispiel mit MariaDB und Centos7 :)

Wer z.B. den tableopencache erhöhen wollte konnte dies schlicht konfigurieren. Der Prozess startete als user root und hatte keine limit Probleme.

Im service File von Centos läuft der Prozess gleich als Unix User mysql.

[Service]
Type=simple
User=mysql
Group=mysql
..

Dieser User ist nicht in der Lage seine limits nach oben zu veränden. In dem Error Log sollte etwas in folgender Art zu lesen sein:

150303 11:57:02 [Warning] Changed limits: max_open_files: 1024  
 max_connections: 214  table_cache: 400

Netter Weise ist im Service File selbst ein Hinweis auf LimitNOFILE. Nur wer liest das Service File?

Und bitte wie dort dokumentiert die Erweiterung als eigene Datei unter /etc/systemd/system/mariadb.service.d/limits.conf anlegen. Ob es nun limits heißt, ist egal. Bitte nicht die Dateien unter /usr/lib/systemd/system ändern. Die gehören dem Paketmaintainer und sind beim nächsten Update eventuell weg:)

Viel Spaß

Erkan

P.S.: Das Centos Service File selbst ruft /usr/bin/mysqld_safe auf. Halte ich ja für mehr als schlecht. Aber das ist eine andere Geschichte ;)