En fait, le nouveau comportement en question ici, c'est pas tout à fait systemd mais logind. Sur une machine de calcul, lorsque tu lances un job via un scheduleur, il t'ouvre un cgroup ayant un cpuset, un memset... A la fin de ta session (walltime), le cgroup est supprimé avec tout ce qu'il y a avec. Job qui ne finit pas dans les temps ==> nettoyer !
En fait, logind fait exactement la même chose, désormais, il nettoie tout en fin de session via les mêmes mécanismes.
En fait, il faut JUSTE ré-écrire nohup pour qu'il ouvre une nouvelle session indépendante, dans un autre cgroup. Cela me parait tout à fait convenable et peut se faire via une IHM simple ;-) Il a été pris l'exemple de mosh plus haut et couplé à tmux, c'est hyper pratique (et simple)...
[^] # Re: systemd, le nouveau Multics
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 8.
En fait, le nouveau comportement en question ici, c'est pas tout à fait systemd mais logind. Sur une machine de calcul, lorsque tu lances un job via un scheduleur, il t'ouvre un cgroup ayant un cpuset, un memset... A la fin de ta session (walltime), le cgroup est supprimé avec tout ce qu'il y a avec. Job qui ne finit pas dans les temps ==> nettoyer !
En fait, logind fait exactement la même chose, désormais, il nettoie tout en fin de session via les mêmes mécanismes.
En fait, il faut JUSTE ré-écrire nohup pour qu'il ouvre une nouvelle session indépendante, dans un autre cgroup. Cela me parait tout à fait convenable et peut se faire via une IHM simple ;-) Il a été pris l'exemple de mosh plus haut et couplé à tmux, c'est hyper pratique (et simple)...