Re: service user et timers

dans systemd, tu dois te taper 10 lignes réparties dans 2 fichiers au minimum.

Je reconnais ne pas connaître les détails pour systemd, c'est peut-être moins concis, certes, je n'ai personnellement pas de bonne solution pour ça (ne faisant que très très rarement des planification de tâches, et jamais avec systemd).
Par contre, pour cron, j'ai ce genre de choses:

% cat /etc/cron.d/e2scrub_all 
30 3 * * 0 root test -e /run/systemd/system || SERVICE_MODE=1 /usr/lib/x86_64-linux-gnu/e2fsprogs/e2scrub_all_cron
10 3 * * * root test -e /run/systemd/system || SERVICE_MODE=1 /sbin/e2scrub_all -A -r

Désolé, mais... j'ose espérer que systemd à quand même une config plus lisible.
Je préfère un truc verveux (bon, que ça soit coupé en 2 fichiers c'est dommage par contre) plutôt qu'un one-liner illisible sans être lourdement commenté (encore, ici, «la chance!» seul root est utilisé, donc tout s'aligne, et il n'y a que 2 lignes...).

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...
Idéalement, je teste sur plusieurs périodes (jours/heures... pour les semaines ou les mois, c'est pas possible, et je crois qu'il peut pas gérer les années) que ça fonctionne vraiment, et dans tous les cas, je serre les fesses de pas m'être raté.

Le tout, alors que fonctionnellement le but est simplement de gérer des processus et leurs journaux, ce qui est très clairement du ressort d'outils comme systemd ou les daemontools (sauf que eux n'ont pas cette fonctionnalité, sauf peut-être nosh?).
J'ai beau ne pas être fan de systemd, il me semble difficile de considérer que sysVinit+rc.d+cron est une solution magnifique.
daemontools|runit + cron est un peu moins bancal, mais on se tape quand même le fait que les gestionnaires de processus sont incapables de planifier la gestion de processus, ce qui est pourtant leur coeur de métier...

En pratique, si ma machine est censée fonctionner non-stop, plutôt qu'installer cron, je préfère faire ça:

#!/bin/sh
#./run
# une "lib" de 26 lignes que je me suis faite
. /etc/runit/common
echo "starting $SVNAME"
test -e ./conf || die "config not found"
exec $COMMAND

#!/bin/sh
#./finish
. /etc/runit/common
test -e ./conf || die "config not found"
sleep $PERIOD

#./conf
PERIOD="1d"
COMMAND="foobar"

Ces fichiers sont placés dans un dossier type /etc/sv/task_$foo, qui contiens un sous dossier log, qui contiens un fichier run qui est un symlink vers /etc/runit/log.run.
Du coup, ça fait pas mal de monde pour de simple tâches planifiées.

Le résultat est moins bon et moins puissant qu'avec systemd (en plus ça pourrit mon arbo de processus :/) ou cron (sans parler d'anacron!), mais...
Comparé à cron, j'ai nettement plus confiance dans le fonctionnement ainsi qu'une meilleure facilité pour consulter les journaux d'une tâche spécifique.

Par chance je n'ai que rarement besoin d'y avoir recours. Sinon, le poids sur le système pourrais devenir problématique (dans le cas de runsvdir, il lance à chaque fois un processus pour gérer le daemon lui-même, et un autre pour les logs, ça fait donc 2 processus constants pour des tâches qui ne nécessitent des ressources que ponctuellement. Ce n'est pas énorme, mais c'est tout de même dommage de gaspiller, et ça ne se mets pas à l'échelle, contrairement à cron ou... systemd.)

Ici, je pense que systemd gagne haut la main.