Re: service user et timers

Tu prends un exemple tiré par les cheveux comme justificatif argumentaire ...qui au passage n'est pas si justifié que ça.

1. Crontab traditionnel attend "une commande" point barre. Que ta commande soit kilométrique (du fait des chemins à rallonge ou des noms trop long ou les deux comme dans ton cas avec /usr/lib/x86_64-linux-gnu/e2fsprogs/e2scrub_all_cron) ou que tu utilises les possibilités de l'interpréteur de commande pour faire des tests et enchaînements de commandes (comme dans ton exemple test -e /run/systemd/system || SERVICE_MODE=1 /sbin/e2scrub_all -A -r) n'empêche qu'on attend là quelque chose vu comme une seule commande (même si en pratique ce peut être un bloc comme tu le fais ou un appel de fichier de script comme on fait traditionnellement.) Ah ça tombe bien, c'est la même chose avec le systemd-timer : tu as une ligne qui indique la commande et c'est toujours ne commande qui sera toujours à rallonge dans ton cas.
2. Crontab est un tableau (c'est le sens du tab dans le nom) et ce que tu appelles un « one-liner » n'est qu'une ligne du tableau et c'est tout aussi lisible qu'un fichier CSV ou TSV (ah tiens, on peut utiliser des tabulations à la place des espaces dont le nombre n'est pas limité si tu tiens vraiment à indenter, mais bon...)

Systemd-timer n'utilise pas un tableau regroupant toutes les tâches et leur périodicité, mais deux fichiers par unit de timer ; ce qui convient aux gens qui aiment avoir les chosent éparpillées un peu partout et démultiplier les fichiers. Mais comme il y a des commandes pour masquer le bazar sous-jacent ça plait.

Les rares fois ou je dois utiliser cron, je lis le manuel, plusieurs fois pour être sûr, puis j'écris une ligne, et je la relis plusieurs fois, en comptant les espaces...

La plupart des distributions Linux aujourd'hui, en tout cas pour CentOS et Debian, le fichier commence par des lignes de commentaire qui indique l'ordre des champs

# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user command to be executed

Quand ça n'y est pas, je rajoute perso une ligne laconique du genre

# mm hh jj MMM JJJ user task-job 

Il est facile d'écrire une interface, comme le font

• des services web d'hébergement de cron (Cf. setCronJob, webCronJob, easyCron, ou encore cron-job par exemple)
• des services d'administration d'hébergement comme webmin, [cPanel], Ajenti, etc.
• des programmes installés en local, comme : crontab-ui (web), Gnome Schedule (X/GTK), Zeit (X/Qt), cron-gui-launcher (X/Bash), et certainement d'autres

Il est enfin possible de nos jours de s'aider un site web pour les usages rares/occasionnels sans y passer du temps : corntab, cronhub, cronmaker, free formater, crontab generator, crontab guru, rakko tools, etc.
cronjob predicator et cron expression descriptor eux sont utiles dans l'autre sens en quelque sorte.

"It is seldom that liberty of any kind is lost all at once." ― David Hume