Mon expérience pour avoir créé un service systemd démarrant buildbot, qui a tendance à se ramasser :
Quant je le lance, et que ça ne marche pas, systemd me le signale comme un grand et me donne une commande pour voir les sorties du logiciel (sorties standard, pas syslog). Écrire le start/stop dans un init classique aurait globalement été beaucoup plus lourd, avec quelques options je peux faire comprendre comment l'application se comporte, y compris ses comportements, disons, mauvais.
Mon service est aussi paramétrable ; le même fichier me sert à lancer plusieurs buildbots (bon, ça c'est relativement facile avec OpenRC).
journalctl est très bien fait, on peut filtrer, avoir un équivalent de tail -f, il y a des couleurs, etc. Je n'ai pas pour l'instant eu le besoin de dumper le tout dans un fichier texte.
[^] # Re: Et pour une poignée de liens en plus
Posté par laurentb . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 10.
Mon expérience pour avoir créé un service systemd démarrant buildbot, qui a tendance à se ramasser :
Quant je le lance, et que ça ne marche pas, systemd me le signale comme un grand et me donne une commande pour voir les sorties du logiciel (sorties standard, pas syslog). Écrire le start/stop dans un init classique aurait globalement été beaucoup plus lourd, avec quelques options je peux faire comprendre comment l'application se comporte, y compris ses comportements, disons, mauvais.
Mon service est aussi paramétrable ; le même fichier me sert à lancer plusieurs buildbots (bon, ça c'est relativement facile avec OpenRC).
journalctl est très bien fait, on peut filtrer, avoir un équivalent de tail -f, il y a des couleurs, etc. Je n'ai pas pour l'instant eu le besoin de dumper le tout dans un fichier texte.