1) les services avec des actions en plus ( genre, postgresql, dump de la db via le script d'init ).
C'est une chose qui fait pas stricto sensu parti du script d'init. En général, ça a été mis dedans parce le script d'init a besoin de la config du daemon, et sans doute pour des questions d'ergonomie et d'affordance ( ie, pour le modèle mentale de l'utilisateur, le script est la porte d'entrée sur la manipulation du daemon, un dump de la db est une manip de ce genre donc on rajoute la fonction )
Avec systemd, tu doit faire un script à part ( vu que tu peux pu intégrer ça dans le script principal ). Il y a un emplacement spécifique quand tu utilise ça avec service pour garder l'intégration ( genre service pgsql dump va appeler /XXX/pgsql/dump ). La différence entre "j'écris du code que je mets avec un case en plus dans un script" et "j'écris du code que je mets dans un fichier à un endroit spécifique" est pas flagrante. En fait, tu peux juste garder ton script d'init qui fait appel à ton 2eme script.
2) les services qui ne sont pas des daemons classiques. Exemple, tu as un truc à lancer au démarrage, mais c'est pas vraiment un daemon, c'est juste la configuration de l'affichage sur un ecran lcd 4" du nom de la machine ( le seul exemple que j'ai trouvé qui ne soit pas géré autrement ). En gros, tu doit lancer une paire de commande pour charger le matos, et lancer ce que tu veux écrire. Ben ça, oui, tu peux lancer un script shell, ou un programme en C. Ou tu peux lancer les commandes à la suite dans le fichier systemd, avec plusieurs lignes Execstart, en précisant "c'est normal si il reste aucun process à la fin" et "ne fait pas de tracking de PID". IE pour les actions spécifiques, rien n'empeche de faire encore du shell. Après tout, si le but est de lancer des softs, personne ne va vérifier si le soft est en C, en python, en perl, en bash ou autre. Donc pareil, si tu codes bien, tu as fichier que tu appelles depuis un script classiques ou systemd.
Maintenant, en pratique, j'ai du mal à voir ce qui requiert des dizaines de commandes spécifiques au boot, à part le réseau et perso, je pense que ça peut sans doute être mieux intégré et de plus haut niveau que sous la forme d'un script shell.
Mais du coup, est ce que tu penses à autre choses pour "besoins non spécifiques" ?
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 1.
Tu appelles quoi "besoin particulier" ?
À vue de nez je pense que tu veux dire 2 trucs :
1) les services avec des actions en plus ( genre, postgresql, dump de la db via le script d'init ).
C'est une chose qui fait pas stricto sensu parti du script d'init. En général, ça a été mis dedans parce le script d'init a besoin de la config du daemon, et sans doute pour des questions d'ergonomie et d'affordance ( ie, pour le modèle mentale de l'utilisateur, le script est la porte d'entrée sur la manipulation du daemon, un dump de la db est une manip de ce genre donc on rajoute la fonction )
Avec systemd, tu doit faire un script à part ( vu que tu peux pu intégrer ça dans le script principal ). Il y a un emplacement spécifique quand tu utilise ça avec service pour garder l'intégration ( genre service pgsql dump va appeler /XXX/pgsql/dump ). La différence entre "j'écris du code que je mets avec un case en plus dans un script" et "j'écris du code que je mets dans un fichier à un endroit spécifique" est pas flagrante. En fait, tu peux juste garder ton script d'init qui fait appel à ton 2eme script.
2) les services qui ne sont pas des daemons classiques. Exemple, tu as un truc à lancer au démarrage, mais c'est pas vraiment un daemon, c'est juste la configuration de l'affichage sur un ecran lcd 4" du nom de la machine ( le seul exemple que j'ai trouvé qui ne soit pas géré autrement ). En gros, tu doit lancer une paire de commande pour charger le matos, et lancer ce que tu veux écrire. Ben ça, oui, tu peux lancer un script shell, ou un programme en C. Ou tu peux lancer les commandes à la suite dans le fichier systemd, avec plusieurs lignes Execstart, en précisant "c'est normal si il reste aucun process à la fin" et "ne fait pas de tracking de PID". IE pour les actions spécifiques, rien n'empeche de faire encore du shell. Après tout, si le but est de lancer des softs, personne ne va vérifier si le soft est en C, en python, en perl, en bash ou autre. Donc pareil, si tu codes bien, tu as fichier que tu appelles depuis un script classiques ou systemd.
Maintenant, en pratique, j'ai du mal à voir ce qui requiert des dizaines de commandes spécifiques au boot, à part le réseau et perso, je pense que ça peut sans doute être mieux intégré et de plus haut niveau que sous la forme d'un script shell.
Mais du coup, est ce que tu penses à autre choses pour "besoins non spécifiques" ?