Tag Archives: systemd

UNIX & Linux

systemd delayed service restart

Ich habe einige Monate damit rumgemacht, dass das Konglomerat Telegraf/Prometheus/Grafana von ziemlich starken Abhängigkeiten bei der Startreihenfolge der beteiligten Systeme geplagt ist. Meine Server rebooten alle einmal pro Woche automatisch innerhalb eines gewissen Zeitfensters und seit Grafana musste ich so alle 2-3 Wochen manuell eingreifen und Services neustarten, da insbesondere Telegraf davon ausgeht, dass Schnittstellen, auf die es selbst zugreift, beim eigenen Start erreichbar sein müssen. (Siehe auch: Fallacies of distributed computing.)

Die Frage war also, wie sieht die einfachste Lösung aus, um einen gegebenen Service 60 Minuten nach seinem Start noch einmal automatisch durchzustarten (mit sporadischen Lücken in den Daten kann ich am frühen Sonntagmorgen leben).

Timer und dedizierte Service-Units zu verteilen schien mir zu aufwändig, und ich habe unangenehm lange gegrübelt, wie die simpelste Lösung aussehen könnte, die einfach per systemctl edit foo.service (oder per anderweitig verteiltem systemd drop-in, ymmv) in die betreffende Unit eingebracht werden kann.

Angekommen bin ich schließlich bei dieser Bandwurmzeile:

# /etc/systemd/system/telegraf.service.d/override.conf
[Service]
ExecStartPost=-+sh -c 'systemctl --quiet is-active %N-restart || systemd-run --unit=%N-restart --on-active=1h systemctl restart %N'

Von rechts nach links:

  • systemd-run instanziiert einen transienten timer und service, der in einer Stunde systemctl restart ausführen wird. %N wird dabei durch den Namen der übergeordneten Unit (hier also: telegraf) ersetzt.
  • Der Name des transienten timer und service wird über die Option --unit vorgegeben um im vorherigen Schritt (eins weiter links) vorhersagbar zu sein.
  • systemd-run wird nur dann ausgeführt, wenn nicht bereits eine Unit aktiv ist, die den vorgegebenen Namen hat, den die transiente Unit bekommen würde, wenn sie noch auszuführen wäre.
  • Das ganze ist als Shell-Aufruf gewrappt, um den || – Operator zu haben.
  • ExecStartPost=+ führt als root aus, obwohl die übergeordnete Unit ihre Befehle unprivilegiert ausführt.
  • ExecStartPost=- ignoriert den Fehler aus dem Shell-Einzeiler, wenn die Unit bereits aktiv war. Es könnte ersatzweise auch ; true ans Ende des Einzeilers geschrieben werden.

Too Good To, UNIX & Linux

Too good to #0010

In today’s installment:

  • “Headless” Nextcloud
  • Monitoring of fork activity

Mount Nextcloud files via rclone+Webdav, as a systemd user unit

# ~/.config/systemd/user/nextcloud-mount.service
[Unit]
Description=Mount Nextcloud via rclone-webdav

[Service]
ExecStartPre=mkdir -p %h/Nextcloud
ExecStart=rclone mount --vfs-cache-mode full --verbose nextcloud_webdav: %h/Nextcloud/
ExecStop=fusermount -u %h/Nextcloud/
ExecStopPost=rmdir %h/Nextcloud

[Install]
WantedBy=default.target

Sync instead of mount

Nextcloud via Webdav is absurdly slow, so maybe use nextcloudcmd instead, which unfortunately does not have its own daemonization:

# ~/.netrc (chmod 600)
machine my.nextcloud.example.com
login myuser
password *** (app password)

# ~/.config/systemd/user/nextcloudcmd.service
[Unit]
Description=nextcloudcmd (service)

[Service]
ExecStart=nextcloudcmd -n --silent %h/Nextcloud https://my.nextcloud.example.com

# ~/.config/systemd/user/nextcloudcmd.timer
[Unit]
Description=nextcloudcmd (timer)

[Timer]
OnStartupSec=60
OnUnitInactiveSec=300

[Install]
WantedBy=default.target

forkstat (8) – a tool to show process fork/exec/exit activity

High load without a single obvious CPU consuming process (not related to the Nextcloud shenanigans above) led me to forkstat(8):

Forkstat is a program that logs process fork(), exec(), exit(), coredump and process name change activity. It is useful for monitoring system behaviour and to track down rogue processes that are spawning off processes and potentially abusing the system.

$ sudo forkstat # (that's all)
Too Good To, UNIX & Linux

Too good to #0009

1 Comment

In this episode:

  • urlwatch for new daily Ubuntu Server ISO
  • systemd-run ephemeral timers as replacement for at
  • Mozillateam Firefox on Debian
  • systemd service: ExecStartPre as root
  • gdm3 autosuspend/shutdown behaviour

urlwatch for new daily Ubuntu Server ISO

Somewhat desparate because at the time of starting this post, the (pre-beta, non-LTS, not blaming anyone) server image in question was badly broken.

---
name: Ubuntu Server Daily ISO
url: https://cdimage.ubuntu.com/ubuntu-server/daily-live/current/SHA256SUMS
filter:
  - grep: .*-live-server-amd64.iso
---

systemd-run ephemeral timers as replacement for at

Goes great with “hardened” systems that deny use of at(1).

Run a command 60 seconds from now, via the user’s private systemd (after logout only if session lingering is enabled).

systemd-run --user --on-active=60s -- logger --tag foo "Hello world"

Run a command 2 minutes from now, privileged or as a specific user via the global systemd:

sudo systemd-run --uid="${LOGNAME}" --on-active=2m -- touch /tmp/hello

Insights

systemctl --user list-timers
journalctl --user -u 'run-*.timer'
sudo systemctl list-timers
sudo journalctl -u 'run-*.timer'

Mozillateam Firefox on Debian

$ sudo tee /etc/apt/sources.list.d/mozillateam-ppa.list <<Here
deb https://ppa.launchpadcontent.net/mozillateam/ppa/ubuntu jammy main
deb-src https://ppa.launchpadcontent.net/mozillateam/ppa/ubuntu jammy main
Here

$ sudo tee /etc/apt/trusted.gpg.d/mozillateam.asc < <(curl 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x0ab215679c571d1c8325275b9bdb3d89ce49ec21')

systemd service: ExecStartPre as root

[Service]
...
User=nonroot
Group=nonroot
ExecStartPre=+install -d /var/lib/theservice -o nonroot -g nonroot
ExecStart=/usr/sbin/theservice

See systemd.service, “special executable prefixes”.

gdm3 autosuspend/shutdown behaviour

Debian:

$ sudo apt-get install dbus-x11
$ sudo chsh -s /bin/bash Debian-gdm
$ sudo -i -u Debian-gdm
$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type
'suspend'
$ dbus-launch gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type nothing
$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type
$ exit
$ sudo chsh -s /bin/false Debian-gdm

Arch/Garuda:

$ sudo chsh -s /bin/bash gdm
$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type
'suspend'
$ dbus-launch gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type nothing
$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type
$ exit
$ sudo chsh -s /usr/bin/nologin gdm
Too Good To, UNIX & Linux

Too good to #0008

rinetd-style circuit level gateway in systemd

This accepts port 465/tcp and forwards all connections to a service running somewhere else on 1194/tcp.

The socket unit accepts the connection on port 465:

# /etc/systemd/system/tcp465-to-tcp1194.socket
[Unit]
Description="openvpn 465/tcp to 1194/tcp (socket)"

[Socket]
ListenStream=465

[Install]
WantedBy=sockets.target

systemd-socket-proxyd connects to the backend:

# /etc/systemd/system/tcp465-to-tcp1194.service
[Unit]
Description="openvpn 465/tcp to 1194/tcp (service)"

[Service]
ExecStart=/lib/systemd/systemd-socket-proxyd 10.12.13.14:1194
User=proxy

(Anyone old enough to remember that this was called a plug-gateway in the TIS Firewall Toolkit?)

Python pip/virtualenv/pipenv micro-HOWTO

Clone project with wacky dependencies:

git clone https://github.com/example/project.git

Install dependencies (from requirements.txt):

pipenv install (-r requirements.txt)

Run:

pipenv run ./script

Template for git commit message

Create the template, I prefer it outside the repository:

(blank line)
(blank line)
foo#1234 is the neverending story I'm constantly working on

Configure the path, relative to the repository root:

git config commit.template ../commit-template-for-foo.txt
python, Too Good To, UNIX & Linux

Too good to #0007

Disable the dynamic motd on Ubuntu and everywhere else

This is without messing around in /etc/pam.d or doing things that may be reverted by future updates. Remember to systemctl enable disable-dynamic-motd.timer.

# /etc/systemd/system/disable-dynamic-motd.timer
[Unit]
Description=Disable all the dynamic-motd scriptlets (timer)

[Timer]
OnBootSec=10
OnActiveSec=3600

[Install]
WantedBy=timers.target

# /etc/systemd/system/disable-dynamic-motd.service
[Unit]
Description=Disable all the dynamic-motd scriptlets (service)

[Service]
Type=oneshot
ExecStart=sh -c 'chmod -v -x /etc/update-motd.d/*'

Disable verbose logging on realmd.service

Problem on AD-member Linux client, realmd logs thousands of redundant messages:

Feb 01 11:11:34 kvm-28ca realmd[22302]: client using service: :1.1042
Feb 01 11:11:34 kvm-28ca realmd[22302]: holding daemon: :1.1042
Feb 01 11:11:34 kvm-28ca realmd[22302]: client gone away: :1.1042
Feb 01 11:11:34 kvm-28ca realmd[22302]: released daemon: :1.1042

Solution, disable debug logging in the systemd unit by introducing this drop-in:

# /etc/systemd/system/realmd.service.d/override.conf
[Service]
LogLevelMax=info

Sorting Debian package versions

dpkg –compare-versions is not exactly a secret, but I’ve wrapped a script around it to visualize and better wrap my head around non-straightforward naming schemes:

$ cat test.txt
2.1
2.2~pre01
1.0
2022-01.1~pre03
2.1-bugfix-foo
2.1~bugfix-foo
2.2
2022-01~foo~bar
2022-01
1.0
0
3
2022-01~foo

$ ./dpkg-sort-versions < test.txt
Sorted from lowest (oldest) to highest (latest):
0
1.0
1.0
2.1~bugfix-foo
2.1
2.1-bugfix-foo
2.2~pre01
2.2
3
2022-01~foo~bar
2022-01~foo
2022-01
2022-01.1~pre03

Script is here.

Allgemein, UNIX & Linux

systemd-Timer für Crontab-User

5 Comments

Ich bin wirklich dazu übergangen, mich komplett auf systemd-Timer statt Crontab-Einträge einzulassen, lediglich die Zeitangaben für kalendergebundene Events machen mir dauerhaft zu schaffen. Mir ist ein Rätsel, dass die allwissenden systemd-Entwickler darauf verzichtet haben, eine zusätzliche Konfigurationsmöglichkeit über die bekannten, selbsterklärenden und intuitiv verständlichen Crontab-Spezifikationen zu akzeptieren. Hier also eine Handvoll Beispiele:

WannCrontabOnCalendar
Täglich um Uhr45 13 * * *13:45:00
Alle 5 Minuten*/5 * * * **:00/5:00
Montags, Mittwoch, Donnerstag um Uhr14 9 * * 1,3,5Mon,Wed,Fri 09:14:00
Montag bis Freitag um Uhr0 4 * * 1-5Mon..Fri 04:00:00
Jeden Monatsersten um Uhr0 6 1 * **-*-1 06:00:00
Alle 5 Minuten von 06:00 – 17:55*/5 6-17 * * *06..17:00/5:00
⚠️ Achtung: In der Tabelle sind non-breakable Spaces enthalten. ⚠️
Die Werte sind somit nicht für copy&paste geeignet.

Zum Testen mit systemd-analyze wird die jeweilige Definition mit Anführungszeichen übergeben:

systemd-analyze calendar --iterations=10 'Mon,Wed,Fri 09:14:00'

In der Timer-Unit dürfen dann keine Anführungszeichen stehen, und nein, das ergibt überhaupt keinen Sinn.

[Unit]
Description=Ein kalenderbasierter Timer

[Timer]
OnCalendar=Mon,Wed,Fri 09:14:00

[Install]
WantedBy=timers.target

Alternativ, insbesondere bei hoher Ausführungsfrequenz oder bei Überschneidungsgefahr, benutze ich, wenn ich schon in systemd unterwegs bin, heute gern monotone Timer.

[Unit]
Description=Ein monotoner Timer

[Timer]
OnStartupSec=60
OnUnitInactiveSec=900

[Install]
WantedBy=timers.target

Versuche, hybride Timer mit Elementen aus beiden Timer-Typen zu konfigurieren, haben bei mir keine Fehlermeldungen produziert, aber der OnCalendar-Teil der Konfiguration wurde ignoriert. Das genaue Verhalten scheint nicht definiert zu sein.

WantedBy sollte bei Timern im Systemkontext auf timers.target lauten, da damit die NTP-Synchronisation vorm Start des Timer sichergestellt ist. Im Userkontext (Wallpaperchanger, Zeiterfassung, dies das) steht nur default.target zur Verfügung.

Inb4, warum überhaupt auf systemd-Timer statt crontab einlassen? Ganz einfach, weil systemd-Timer absolut narrensicher zu managen sind:

  • Du willst einen systemd-Timer verteilen/managen/paketieren? Kein Problem. Zwei Dateien nach /etc/systemd/system packen, systemctl daemon-reload, systemctl enable, fertig. Anders als in der Crontab musst du dir keine Meta-Syntax ausdenken, um zu identifizieren, ob der Eintrag schon da ist, und um ihn punktgenau löschen zu können.
  • Du willst einen vorinstallierten Timer anpassen? Ebenfalls kein Problem. Du legst ein Drop-In daneben, in dem du deine neue Timer-Spezifikation hinterlegst, etwa /etc/systemd/system/apt-daily.timer.d/local.conf als Drop-In für /lib/systemd/system/apt-daily.timer.

Grundlagen zu Timern finden sich etwa im Arch-Wiki oder bei Ubuntu Users.

Too Good To, UNIX & Linux

Too good to #0004

1 Comment

systemd, the good parts: monotonic timers

When systemd makes you suffer because “run job every 10 minutes” is infinitely harder to specify than in crontab, remember there are monotonic timers in systemd that aren’t derived from wallclock time, or “Calendar Events” as they call it.

Run timer once 60 seconds after system startup, then every 10 minutes after the job finished:

# /etc/systemd/system/demo.timer
[Unit]
Description=demo monotonic timer

[Timer]
OnStartupSec=60
OnUnitInactiveSec=600

[Install]
WantedBy=timers.target    # When in a system session
# WantedBy=default.target # When in a user session (~/.config/systemd, systemctl --user etc.)

Python: Use tabulate to format output in columns 

#!/usr/bin/env python3
from tabulate import tabulate

data = [
	[ 'foo', 'bar', 'baz' ],
	[ 'spam', 'eggs', 'bacon' ]
]

headers = ['Eine', '2', 'Whatever']

print(tabulate(data, headers=headers, tablefmt='simple'))

Output:

$ ./tab.py 
Eine    2     Whatever
------  ----  ----------
foo     bar   baz
spam    eggs  bacon

virsh/libvirt, automate key presses

(* Updated to sleep 5 seconds after each keypress.)

for key in R E I S U B; do virsh send-key "${domain}" KEY_LEFTALT KEY_SYSRQ KEY_${key}; sleep 5; done