C'est pas pour être méchant, mais dans le strict cadre du projet systemd, cet extrait de log n'apporte rien. Ca serait la glibc ou le kernel il n'y aurait aucun soucis - mais avec systemd si l'option par défaut sur un composant de systemd a une valeur, il ne vaut mieux pas y toucher.
Et ce pour trois raisons
1 - L'équipe de dev systemd a la fâcheuse habitude de n'en n'avoir strictement rien à faire des gens qui modifient les options par défaut. Le nombre de bugs remontés sur la mailling list qui se terminent par un "won't fix" avec un laconique "we do not see the interest in testing this configuration" est loin d'être nul. Que les choses soient claires, il est tout à fait possible qu'à partir de maintenant la team systemd considère que l'option est à yes dans tout le code qu'ils écrivent - on a déjà vu ce type de comportement pour les cgroups, udev, les sockets unix etc.
2 - Même si on met l'option à false, le scope est "abandonné" en cas de fermeture de session. CF freedesktop - Ca veut dire quoi un scope abandonné ? Ben systemd ne le gère plus. Autant dire que ca va être chaud de récupérer un process de ce scope, ou de le terminer proprement.
3 - C'est super savonné quand même. Logind gère un certains nombre de fonctions assez utile (et parfois nécessaires) - et lui quoi qu'il arrive il va clore les informations, accès, canaux dbus etc lié au login de l'utilisateur. Donc si votre programme "détaché" a besoin d'accéder à ces fonctions, il va de toute façon se vautrer comme une loutre bourrée à la bière à la fermeture de session.
La seule option pour avoir un comportement "presque" normal est de laisser la valeur à yes mais de lancer tout les processus qui sont susceptible de devoir être détachée dans des scope services utilisateurs tout en ayant l'option lingering activé.
Enabling lingering allows the user to run processes without being logged in, for example to allow screen to persist after the user logs out, even if the session scope is terminated.
Enabling lingering means that user@.service is started automatically during boot, even if the user is not logged in
En d'autres termes vous allez créer un sous scope de votre user.service à chaque fois que vous allez lancer un tmux/screen. Ce sous-scope va avoir un nom très pratique genre run-r14b0047ab6df45bfb45e7786cc839e76.scope.
Ce sous-scope va être relancé systématiquement au boot de la machine. Donc il ne faut pas oublier de faire le ménage de temps en temps. Bien sur si vous avez de vrais services utilisateurs qui doivent être lancé à chaque boot, il ne faut pas se planter pendant le ménage.
[^] # Re: Depuis NEWS
Posté par Kaane . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 10.
C'est pas pour être méchant, mais dans le strict cadre du projet systemd, cet extrait de log n'apporte rien. Ca serait la glibc ou le kernel il n'y aurait aucun soucis - mais avec systemd si l'option par défaut sur un composant de systemd a une valeur, il ne vaut mieux pas y toucher.
Et ce pour trois raisons
1 - L'équipe de dev systemd a la fâcheuse habitude de n'en n'avoir strictement rien à faire des gens qui modifient les options par défaut. Le nombre de bugs remontés sur la mailling list qui se terminent par un "won't fix" avec un laconique "we do not see the interest in testing this configuration" est loin d'être nul. Que les choses soient claires, il est tout à fait possible qu'à partir de maintenant la team systemd considère que l'option est à yes dans tout le code qu'ils écrivent - on a déjà vu ce type de comportement pour les cgroups, udev, les sockets unix etc.
2 - Même si on met l'option à false, le scope est "abandonné" en cas de fermeture de session. CF freedesktop - Ca veut dire quoi un scope abandonné ? Ben systemd ne le gère plus. Autant dire que ca va être chaud de récupérer un process de ce scope, ou de le terminer proprement.
3 - C'est super savonné quand même. Logind gère un certains nombre de fonctions assez utile (et parfois nécessaires) - et lui quoi qu'il arrive il va clore les informations, accès, canaux dbus etc lié au login de l'utilisateur. Donc si votre programme "détaché" a besoin d'accéder à ces fonctions, il va de toute façon se vautrer comme une loutre bourrée à la bière à la fermeture de session.
La seule option pour avoir un comportement "presque" normal est de laisser la valeur à yes mais de lancer tout les processus qui sont susceptible de devoir être détachée dans des scope services utilisateurs tout en ayant l'option lingering activé.
CF freedesktop
Il y a un défaut tout de même :
En d'autres termes vous allez créer un sous scope de votre user.service à chaque fois que vous allez lancer un tmux/screen. Ce sous-scope va avoir un nom très pratique genre run-r14b0047ab6df45bfb45e7786cc839e76.scope.
Ce sous-scope va être relancé systématiquement au boot de la machine. Donc il ne faut pas oublier de faire le ménage de temps en temps. Bien sur si vous avez de vrais services utilisateurs qui doivent être lancé à chaque boot, il ne faut pas se planter pendant le ménage.