Category Archives: Allgemein

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.

Allgemein

How to get rid of the plus signs in Bonnie++ output

1 Comment

I’m confident that many of you have seen this countless times when using the popular “standard” harddisk benchmarking tool, Bonnie++:

# bonnie++ -u root -d /mnt/1
Version 1.03d       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
grml             8G 51447  98 129399  39 56253  16 43505  97 136526  16 985.2   1
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++


The manpage explains this as follows:

If a test completes in less than 500ms then the output will be displayed as “++++”. This is because such a test result can’t be calculated accurately due to rounding errors and I would rather display no result than a wrong result.

You will most likely see this for the lower “Create” section of Bonnie++. While the tests from the upper “Input/Output” section always make an educated guess and use twice the size of RAM, the “Create” tests have no way of guessing the proper number of files. Look for the word “files” near the left: Bonnie++ always defaults to this 16 x 1024 files for testing. Indeed, munging 16000 files in less than half a second sounds like no big task for a fast system.

Bonnie++ takes an option that instructs it to use more files for the “Create” tests, e.g. -n 128 tells it to test with 128 x 1024 files. In this second run, I’ll also disable the “Input/Output” tests by setting -s0:

# bonnie++ -u root -d /mnt/1 -s 0 -n 128
Version 1.03d       ------Sequential Create------ --------Random Create--------
grml                -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                128 46336  84 +++++ +++ 31277  50 32574  65 +++++ +++ 12803  23


We now get values for file creation and deletion, but reads are still excessively fast. Since Bonnie++ discarded the measurement because it finished within less than 500 ms, it may be possible to estimate that the system is capable of performing at least (128 x 1024 x 2 = 262144) read operations per second.

Further increasing the number may not be possible due to lack of inodes on your filesystem. Also, such an extremely high number of files and file operations may decrease overall file system performance.
The system used for testing was a dual AMD Opteron 285 with a hardware RAID 0 of 3 UW320 disks @ 15k RPM.