Schlagwörter-Archiv: systemd

btrfs auf LUKS mit systemd

Veröffentlicht am von — Keine Kommentare ↓

Systemd scheitert momentan noch am Erkennen der Abhängigkeiten von multi-volume btrfs Dateisystemen auf LUKS-Basis.

Mein aus vier LUKS-Volumes (btrfs-RAID1) bestehendes Archiv wird in der /etc/fstab so eingebunden:

/dev/mapper/archive1	/mnt/archive	btrfs	device=/dev/mapper/archive1,device=/dev/mapper/archive2,device=/dev/mapper/archive3,device=/dev/mapper/archive4,defaults,noatime,nodiratime	0 0

systemd erkennt dabei allerdings nur die Abhängigkeit zu /dev/mapper/archive1, und versucht es folgerichtig schon nach dessen Auftauchen einzubinden, was oft fehlschlägt weil die restlichen Volumes noch nicht angelegt sind.

Bis zu einem Upstream-Fix hilft ein manuelles .mount-File für den entsprechenden fstab-Eintrag, also in meinem Fall /etc/systemd/system/mnt-archive.mount:

[Unit]
Description=/mnt/archive
Wants=cryptsetup.target
After=cryptsetup.target
 
[Mount]
What=/dev/mapper/archive1
Where=/mnt/archive
Type=btrfs
Options=defaults,noatime,nodiratime

(Der Dateiname ist hier wichtig, da er das automatisch aus der fstab generierte .mount-File überlagern muss!)

EDIT: Ab munin-node-2.0.4-1 ändert sich u.A. der Pfad zum Binary, daher muss das .service-File angepasst werden:

[Unit]
Description=Munin Node Service
After=syslog.target network.target
 
[Service]
Type=forking
PIDFile=/run/munin/munin-node.pid
ExecStart=/usr/bin/munin-node
 
[Install]
WantedBy=multi-user.target

munin-node mit systemd

Veröffentlicht am von — Keine Kommentare ↓

Für den Betrieb von munin-node unter systemd sind die folgende Service-Unit und ein Eintrag in /etc/tmpfiles.d nötig:

/etc/systemd/system/munin-node.service:

[Unit]
Description=Munin Node Service
After=syslog.target network.target
 
[Service]
Type=forking
PIDFile=/var/run/munin/munin-node.pid
ExecStart=/usr/sbin/munin-node
 
[Install]
WantedBy=multi-user.target

/etc/tmpfiles.d/munin-node.conf:

D /var/run/munin 0755 munin munin -

Linux-Moderne: systemd, journald und kein syslog-ng

Veröffentlicht am von — Keine Kommentare ↓

Lange Zeit (zwei Jahre, 5 Monate und 6 Tage laut /var/log/pacman.log) war ich mit meinem klassischen Setup zufrieden: SysVinit als init-System, syslog-ng als Logger, soweit es geht kein PolicyKit, ConsoleKit, Avahi und all dieses moderne Zeug – alles Schnickschnack! ;)

Aber so ganz will ich mich der Neuerungen dann doch nicht verschließen und so begann ich kürzlich damit, mich über systemd zu informieren (angeregt nicht zuletzt durch den Talk auf der GPN12).
Weil ich mit den Bootzeiten meiner Box trotz SSD nicht zufrieden war (und schon länger mal plymouth ausprobieren wollte) wagte ich dann den Vorstoß und confte mein System auf systemd um (hauptsächlich nach Arch-Wiki).

Tja was soll ich sagen, ~11 Sekunden Bootzeit statt ~35 – das liegt deutlich im spürbaren Bereich (zumindest für Nerds wie mich ;) ). Auch aus technischer Sicht macht es absolut keinen Sinn, auf Parallelisierung zu verzichten: warum sollen sich drei von vier CPU-Kernen langweilen, wenn durch die SSD mehr als genug I/O-Bandbreite für ein parallelisiertes Startprozedere zur Verfügung stünde? Die Verwendung von cgroups und (x)inetd-ähnliches Verhalten bilden dann das Sahnehäubchen bei der Verwendung von systemd gegenüber traditionellen init-Systemen.

Etwas schwierig gestaltete sich dabei das Einbinden meines Ramdisk-Scripts und das korrekte Mounten einer multi-Volume btrfs-Partition auf LUKS-Basis – zu beidem folgen separate Beiträge.

Wo ich schon am Über-Bord-werfen von alten Standardkomponenten war kam mir das Konzept vom systemd-Journal gerade recht: warum eine SSD mit unzähligen Schreiboperationen für persistente Logs belasten? Ich kam ins Grübeln, zu welchen Zwecken ich meine Syslogs verwende: eigentlich nämlich nur zum Erkennen von Laufzeitproblemen (Kernel, Dienste) durch Parsen über logcheck, und abundzu mal zum Recherchieren von Aktionen der Paketverwaltung (/var/log/pacman.log). Mir fiel kein einziger Fall ein, in dem ich die Logs vergangener Tage zu Rate gezogen hätte.
Das Pacman-Log wird nicht über den System-Logdienst geschrieben und ist damit unabhängig, also wagte ich mit dem Wechsel zum systemd-eigenen Journal (journald) mit nicht-persistenten Logs (ich weiß, die kann man auch persistent machen) einen weiteren Versuch.

Die Zeit wird zeigen, welche langfristigen Änderungen sich dadurch ergeben – ich werde berichten. Eine schon jetzt geborene Projektidee ist der Ersatz von logcheck durch ein mit journald kompatibles Tool auf Bash-Basis, mal schauen wann ich dafür Zeit finde :)