Non, puisque cela concerne uniquement la minorité de personnes qui va aller regarder ses logs (par quelque moyen que ce soit, par exemple via un outil de monitoring).
Les utilisateurs que j'ai décrit, évidemment, n'iront pas voir.
BTW: As-tu déja utilisé nohup, dans le cadre de sysadmin ? J'imagine que non... Généralement, c'est pour faire nohup mon_script_exceptionnel_que_je_n_veux_pas_interrompre, donc bref une manipulation exceptionnelle (genre un dump de DB, reconstruction raid, etc), pas pour lancer un daemon (ça c'est parfaitement la responsabilité job d'init).
Je n'ai jamais utilisé nohup dans le cadre de sysadmin. Et cela simplement parce que nohup, lorsque je l'utilisais, se révélait toujours être une catastrophe, car bien souvent, on oublie de mettre quelquechose dans le journal, et c'est difficile à gérer. J'ai très vite découvert screen, et donc nohup n'avait plus aucune utilité pour moi depuis ce jour. Surtout pour faire des choses comme des dumps de DB ou des reconstructions de RAID, je préfère avoir clairement en visuel le retour de ces fonctions. Si je suis en local ou quasi local sur le serveur, pas besoin de nohup ou screen, mais si je suis à distance sur une connexion peu fiable (comme internet), dans ce cas, effectivement, j'utilise screen. Même pour des reconstructions de RAID logiciel sur Linux, ça s'effectue en tâche de fond et je n'ai jamais eu besoin de nohup.
Bref "indiquer clairement à init que les process qui restent sont voulus" c'est faire "nohup"... Avec ce comportement par défaut ça sera "systemd-spawn-machinchose --flag-super-important nohup mon_script", ça c'est le progrès... Aussi un "soit-disant sysadmin" utilise généralement différentes versions d'OS et différents OS, tu peux imaginer un peu le casse tête (?).
systemd-run --scope --user , cela n'a rien de compliqué, et un sysadmin digne de ce nom ne s'amuse pas à balancer des process en nohup sur différentes versions d'OS et donc sur plusieurs serveurs en même temps. Il faudrait que ces serveurs soient extrêmement mal gérés pour avoir besoin de faire autant de tâches manuelles non prévues. C'est quand même censé être rare d'avoir à lancer ce genre de trucs. Sur l'unique machine où j'ai un screen en permanence, il est lancé une fois au boot dans une session. Je n'ai besoin que d'un seul screen pour gérer plusieurs serveurs, et je n'ai donc plus besoin de nohup.
De plus, nohup n'indique rien du tout à l'init, l'init reste incapable de faire la différence avec un process qui se comporte mal. Au contraire de systemd-run.
Et des process vandales, j'en ai vu aussi bien à l'école que dans des grandes entreprises, avec par exemple des tonnes de process java zombies qui tuaient à petit feu les performances des serveurs à chaque redémarrage de l'application (obligatoire puisque grosse appli enterprise-ready Java pourrie comme bien souvent). Des problèmes qui parfois datent de plusieurs années et qu'aucun sysadmin ne remarque (j'espère par manque d'expérience).
[^] # Re: Ne pas utiliser, recompiler... ou changer une option.
Posté par ookaze . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 3.
Non, puisque cela concerne uniquement la minorité de personnes qui va aller regarder ses logs (par quelque moyen que ce soit, par exemple via un outil de monitoring).
Les utilisateurs que j'ai décrit, évidemment, n'iront pas voir.
Je n'ai jamais utilisé nohup dans le cadre de sysadmin. Et cela simplement parce que nohup, lorsque je l'utilisais, se révélait toujours être une catastrophe, car bien souvent, on oublie de mettre quelquechose dans le journal, et c'est difficile à gérer. J'ai très vite découvert screen, et donc nohup n'avait plus aucune utilité pour moi depuis ce jour. Surtout pour faire des choses comme des dumps de DB ou des reconstructions de RAID, je préfère avoir clairement en visuel le retour de ces fonctions. Si je suis en local ou quasi local sur le serveur, pas besoin de nohup ou screen, mais si je suis à distance sur une connexion peu fiable (comme internet), dans ce cas, effectivement, j'utilise screen. Même pour des reconstructions de RAID logiciel sur Linux, ça s'effectue en tâche de fond et je n'ai jamais eu besoin de nohup.
systemd-run --scope --user , cela n'a rien de compliqué, et un sysadmin digne de ce nom ne s'amuse pas à balancer des process en nohup sur différentes versions d'OS et donc sur plusieurs serveurs en même temps. Il faudrait que ces serveurs soient extrêmement mal gérés pour avoir besoin de faire autant de tâches manuelles non prévues. C'est quand même censé être rare d'avoir à lancer ce genre de trucs. Sur l'unique machine où j'ai un screen en permanence, il est lancé une fois au boot dans une session. Je n'ai besoin que d'un seul screen pour gérer plusieurs serveurs, et je n'ai donc plus besoin de nohup.
De plus, nohup n'indique rien du tout à l'init, l'init reste incapable de faire la différence avec un process qui se comporte mal. Au contraire de systemd-run.
Et des process vandales, j'en ai vu aussi bien à l'école que dans des grandes entreprises, avec par exemple des tonnes de process java zombies qui tuaient à petit feu les performances des serveurs à chaque redémarrage de l'application (obligatoire puisque grosse appli enterprise-ready Java pourrie comme bien souvent). Des problèmes qui parfois datent de plusieurs années et qu'aucun sysadmin ne remarque (j'espère par manque d'expérience).