Je vois pas ce qu'il y'a de délirant a tuer les process lancés manuellement par un utilisateur quand il se délogge.
Parce qu’un utilisateur peut très bien avoir de bonnes raisons pour vouloir avoir des processus sans avoir de session (liste non exhaustive) :
screen/tmux
un job long terme (encodage d’une video par exemple)
download/seed d’un client bittorrent
programme type seti@home
Sinon non, ça n’a rien de délirant tant qu’une alternative crédible est proposée pour permettre les mêmes fonctionnalités. Je n’en vois pas. Sur le principe, ce serait certainement une bonne idée de faire ça si on créait un système de novo, sans historique à gérer. Scoop : ce n’est pas le cas de Linux.
Si tu veux que ca tourne en tache de fond, fais en un vrai service
La méthode idiomatique pour se faire depuis des décennies c’est de faire une tâche de fond de ce type un orphelin. Pourquoi vouloir à ce point casser une convention qui marche somme toute pas trop mal (pas parfait on est d’accord, mais c’est pas comme si la solution systemd était parfaite elle) ?
systemd ne fournit aucune alternative accessible à l’utilisateur (systemd-run nécessite les droits root, créer un service systemd nécessite les droits root)
systemd ne fournit aucune alternative interopérable
[^] # Re: Et 4 mois plus tôt, chez Debian ...
Posté par Moonz . En réponse au journal systemd: attention à RemoveIPC. Évalué à 3. Dernière modification le 04 octobre 2016 à 17:44.
Parce qu’un utilisateur peut très bien avoir de bonnes raisons pour vouloir avoir des processus sans avoir de session (liste non exhaustive) :
Sinon non, ça n’a rien de délirant tant qu’une alternative crédible est proposée pour permettre les mêmes fonctionnalités. Je n’en vois pas. Sur le principe, ce serait certainement une bonne idée de faire ça si on créait un système de novo, sans historique à gérer. Scoop : ce n’est pas le cas de Linux.
La méthode idiomatique pour se faire depuis des décennies c’est de faire une tâche de fond de ce type un orphelin. Pourquoi vouloir à ce point casser une convention qui marche somme toute pas trop mal (pas parfait on est d’accord, mais c’est pas comme si la solution systemd était parfaite elle) ?
systemd ne fournit aucune alternative accessible à l’utilisateur (systemd-run nécessite les droits root, créer un service systemd nécessite les droits root)
systemd ne fournit aucune alternative interopérable