Ne pas oublier que pour un service systemd, stdin est /dev/null… sinon on peut passer du temps de debug bizarre au moment où on veut passer un script en service systemd… ici socat, qui y est très sensible puisque c'est son seul taff (de gérer des flux).

De nos jours sur un système avec systemd (comme une Debian "à jour" sans bidouille pour l'enlever), logrotate est lancé par un timer systemd, et enregistré en tant qu'unit systemd. Pour faire un run de test, il suffit de le start comme un service normal du coup… trop simple.

Pour tester une configuration logrotate, on peut aussi feinter la date de dernière exécution dans /var/lib/logrotate/status et donc après un start, bien vérifier que tout se passe bien… trop simple aussi, mais j'ai dû chercher pour tout ça, je me dis que ça peut servir souvent plutôt que "flemme".

Je squate de plus en plus /dev/shm sans soucis pour tout ce qui est temporaire/calcul, soit pour économiser des écritures sur carte SD (ou même SSD avant), soit pour la rapidité d'accès et je n'ai jamais eu de problème. Je vais là simplement parce que c'est un tmpfs (~ ramdisk) qui est souvent disponible, en tous cas sur du Debian(-like).
Mais il semblerait que par défaut systemd soit supposé vider les fichiers à la fin de la session d'un utilisateur (typiquement quand on quitte la dernière connexion SSH à une machine). J'ai rencontré ce "problème" seulement maintenant… en mode gros WTF.
Bon à savoir donc (et si vraiment on veut on peut facilement le désactiver avec RemoveIPC=no dans logind.conf apparemment).

Pour pouvoir déverrouiller le disque chiffré de ma VM, je me suis dit que plutôt que de passer par l'interface et le noVNC ou de bidouiller le VNC hors interface, je pourrais utiliser le port série. J'avais déjà joué avec ça dans des VM il y a un moment, bah ça s'est pas trop arrangé.
Avec systemd, maintenant on a bien un getty partout automatiquement, ça c'est pas si mal.
Par contre, les messages de boot et le prompt pour le mot de passe ça a l'air d'être le chantier (et pas à cause de systemd, hein, no troll).
https://github.com/systemd/systemd/issues/9899
Le workaround qu'on retrouve partout, c'est d'installer plymouth… sur une VM serveur etc. je me suis d'abord dit que nope nope nope. Mais en vrai ça juste marche, y'a un thème "text only" par défaut et l'installation a pris…882 ko donc bon si ça fait le job, en vrai, pourquoi pas… bootlogd par exemple ne fonctionne pas avec systemd, donc pas trop d'alternative pour le mot de passe en lui-même donc bidouiller un truc juste pour le blabla de boot c'est pas si utile.
Bref en gros, ajouter un serial au KVM, configurer le cmdline de Linux, configurer grub, installer plymouth et on peut tout faire par les deux moyens (qm terminal et noVNC).

Si jamais systemctl --user marche pas avec cette erreur, il suffit de définir la variable d'environnement qui va bien pour débloquer la situation :
XDG_RUNTIME_DIR=/run/user/$(id -u)
Pas besoin de bricoler avec du dbus ou quoi. On peut l'exporter dans son bashrc par exemple. Probablement dû à un sshd configuré sans PAM dans mon cas mais il y a sûrement d'autres raisons possibles.

J'ai voulu ajouter rapidement un petit daemon à un système Alpine pour qu'il démarre au boot. J'ai donc cherché des infos sur les script openrc. On tombe principalement sur les wiki de Gentoo et Arch, puis enfin celui d'Alpine.
Les deux premiers sont super remplis mais ne disent pas comment définir un user particulier… sauf à redéfinir la fonction start et stop et la ligne start-stop-daemon. Le wiki Alpine dit que la page est en chantier et de pas l'utiliser (et n'en parle pas non plus).
J'ai donc lu la page de man directement, lu les exemples, pris ce qui me semblait minimal, trouvé le paramètre user… pas si compliqué au final. Un peu frustrant. Et pas différent de systemd au final, pour les trolleurs ;)

!/sbin/openrc-run

command=/srv/davmail-4.9.0/davmail.sh
command_args="/srv/davmail-4.9.0/davmail.properties"
pidfile=/var/run/davmail.pid
command_background=true
command_user=davmail
name="Davmail Daemon"

Depuis un moment j'avais des mails de cron sur mon conteneur web, disant que logrotate n'arrivait pas à reload apache. J'ai un peu creusé le problème au début, puis étant bloqué sur systemd parlant de namespace, j'étais resté coincé puis étais passé à autre chose.
Pour compliquer le debug, une fois un restart d'apache effectué, pas de problème pendant "un certain temps"…
Là j'ai retenté ma chance et pouf, je suis tombé sur ce rapport de bug Debian.
En fait, c'est tmpreaper qui nettoie les dossiers de "PrivateTmp" de systemd. Du coup au moment de mettre en place l'environnement pour lancer le reload, systemd n'arrive pas à accéder au namespace du /tmp puisqu'il a été viré !
Un message d'erreur plus explicite de la part de systemd aurait été appréciable. Et le problème n'est pas lié à LXC, ni à apache.
Quick fix (pour être complet) :
TMPREAPER_PROTECT_EXTRA='/tmp/systemd-private/'

Je n'avais jamais entendu parler de busctl… encore un outil de systemd.
La commande sert à interagir avec dbus/sd-bus de manière plus simple et plus intégrée que dbus-send et compagnie.
C'est relativement pratique, par exemple si on veut lister les différentes sessions/seat ouvertes, etc. et il y a un mode tree, monitor, introspect, …

Après avoir changé un disque, impossible de le monter. Enfin si, mount OK, mais après rien dans df, mount ou quoi que ce soit. Monter sur un autre dossier que celui prévu était OK aussi.
En fait le point de montage était bien dans le fstab, mais avec un UUID vide (j'avais généré la ligne mais vu que le disque marchait pas, mon script avait laissé vide l'UUID). Et donc systemd se sentait malin de me le démonter immédiaitement…

juil. 21 15:14:47 sdata4 kernel: EXT4-fs (sdi): mounted filesystem with ordered data mode. Opts: (null)
juil. 21 15:14:47 sdata4 systemd[1]: mnt-rozofs-storages-storage_2_8-0.mount: Unit is bound to inactive unit dev-disk-by\x2duuid.device
juil. 21 15:14:47 sdata4 systemd[1]: Unmounting /mnt/rozofs/storages/storage_2_8/0...

Un systemctl daemon-reload, pour relire le fstab, et hop…
Je suis tombé rapidement sur le post ci-lié mais j'aurais pas pensé à ça tout seul… enfin si, si j'étais tombé sur le bout de journal sus-cité…

Pour désactiver un périphérique bloc (clef / disque USB, …), au lieu d'eject on peut utiliser la méthode moderne (avec du polkit dedans !) :
udisksctl power-off -b /dev/sda
Ceci demandera le mot de passe même en SSH à distance, avec un version texte de l'écran "polkit" qu'on connait.

Upgrade wheezy vers jessie dans un conteneur LXC sur un host lui-même déjà en jessie ? Et sans cracher sur systemd ? Facile, il suffit de rajouter à la config LXC les deux lignes proposées ici (le reste sur getty/udev est déjà de base ou inutile).
lxc.autodev = 1
lxc.kmsg = 0

machinectl n'a pas de moyen simple d'entrer dans un conteneur qui tourne (comme vzctl enter quoi). Mais la solution est toute simple, puisque ce sont de simples cgroups, on peut entrer dans l'environnement d'une VM "à la main", avec une commande qui s'appelle nsenter. Ici un exemple clair :)
A marché chez moi : sudo nsenter -t 1210 -m -u -i -n

§ "Overriding vendor settings"
Je savais qu'on pouvait override une unit systemd fournie par le mainteneur d'un paquet par exemple en la copiant/modifiant dans /etc. En fait on peut aussi n'override qu'un paramètre à la fois : un dossier de config drop-in est prévu !
Donc si on veut juste changer un truc dans une unit, on peut "dériver" de l'unit de base et changeant le paramètre que l'on veut. C'est ce que fait systemctl set-propery.
Un show sur le service montre alors la liste des config drop-in du service :
Drop-In: /etc/systemd/system/systemd-nspawn@jessie.service.d
└─50-MemoryLimit.conf

À faire aussi pour LXC ou les containers nspawn systemd si on veut gérer des limites mémoire.
Avec systemd, quand on a le comptage mémoire par cgroup, on peut utiliser systemd-cgtop pour voir la consommation mémoire de chaque service/slice.
Par contre si on met une limite vraiment basse à un nspawn, on a une erreur inattendue :
Failed at step EXEC spawning /usr/bin/systemd-nspawn: Argument list too long