Jouons avec systemd

Mon employeur utilise un outil propriétaire pour sauvegarder les postes de travail. Cet outil est écrit en java (point négatif) mais fonctionne avec les 3 OS utilisés couramment (MacOS, Linux et Windows).
Modulo quelques réglages (internes à l'appli) pour limiter l'utilisation de CPU et de la bande passante, le fonctionnement de l'application ne gêne absolument pas le fonctionnement normal de la machine et les backups sont fait de façon transparente.

Crashplan (puisque c'est le nom de ce logiciel) fonctionne sous la forme d'un service linux classique qui indexe les fichiers des répertoires à sauvegarder, surveille les modifications et envoie le différentiel par le réseau (sous forme chiffrée). Il y a aussi une interface graphique mais elle ne sert que pour la configuration et les restaurations.

Le problème

J'ai eu un seul problème avec cette application. Au démarrage du laptop, elle a besoin de beaucoup d'inotify pour repérer les fichiers modifiés par rapport à la dernière exécution et gnome-tracker aussi (pour des raisons similaires).

Qu'est-ce qui se passe quand un linux moderne (sous Gnome) n'a plus d'inotify disponible pendant le boot ? La charge monte, monte, monte pendant que les derniers services attendent de démarrer. L'ouverture de session peut bloquer (quand on clique sur son login, on obtient jamais d'invite pour taper son mot de passe) et même quand elle fonctionne, la session n'est pas utilisable avant quelques minutes.

Le problème, c'est qu'augmenter la quantité d'inotify disponibles pour le noyau n'est qu'un contournement et même si cela limite les problèmes, ils ne disparaissent pas complètement.

Systemd 1ère phase

Le second défaut de cette application est qu'elle est livrée avec un script d'init pour sa version linux. Et moi, mon laptop utilise Fedora et donc systemd. Même si systemd peut lancer des scripts d'init, ce n'est pas natif. Et l'écriture de service pour systemd est rapide et simple, même pour un non-programmeur (contrairement aux scripts d'init).

Voici donc ce que cela donne  :

[Unit]
Description=Crashplan Backup Service
After=local-fs.target network.target

[Service]
ExecStart=/usr/local/crashplan/bin/CrashPlanEngine start
ExecReload=/usr/local/crashplan/bin/CrashPlanEngine reload
ExecStop=/usr/local/crashplan/bin/CrashPlanEngine stop
Type=forking
PIDFile=/usr/local/crashplan/CrashPlanEngine.pid

[Install]
WantedBy=multi-user.target

Je me suis largement inspirée d'exemples trouvés sur internet mais le principe est assez simple, notamment pour les dépendances. 

Il faut ensuite activer le service, mais je laisse la recherche google à votre charge. 

Tout est une question de timing

Vous devez vous demander en quoi lancer le service avec systemd plutôt qu'avec le mode de compatibilité de sysinit V règle le problème de saturation des inotify. En rien.
Une deuxième étape est venue plus tard, lorsque j'ai découvert l'existence des timer dans systemd. Ils permettent de retarder le lancement d'un service d'un temps déterminé (et pas seulement de dire "lancement de NFS après le réseau").
J'ai donc pu ajouter l'unit systemd suivant :

[Unit]
Description=hold the launch of crashplan of 5 minutes

[Timer]
OnBootSec=5m
Unit=crashplan.service

[Install]
WantedBy=multi-user.target

Crashplan se lance 5 minutes après le boot, l'ouverture de ma session n'est plus ralentie et tout fonctionne parfaitement