Après avoir ajouté un groupe, déconnexion + connexion n'est pas suffisant dans 18.04?
Dans Ubuntu 18.04 avec le bureau par défaut, le comportement de la déconnexion/de la connexion a changé:
Auparavant sur un système Ubuntu, lorsque je constatais que je devais ajouter mon identifiant utilisateur à un groupe, il suffisait de:
Sudo adduser ludwig docker # adds me to group docker
et puis j'ai dû me déconnecter et me reconnecter pour que le changement de groupe soit effectif.
Je remarque qu'avec Ubuntu 18.04, après l’ajout du groupe, la déconnexion et le retour, la liste des groupes effectifs reste inchangée.
En guise de solution de contournement, j'ai redémarré le système, ce qui est peu pratique (nécessite de faire le bon choix dans grub et de ressaisir le mot de passe de chiffrement du disque).
- Pourquoi le comportement est-il comme ça maintenant?
- Puis-je faire quelque chose d'autre à court de redémarrage?
(Je sais que je peux utiliser ssh sur localhost et obtenir les bons groupes uniquement dans la session ssh. C'est aussi trop gênant.)
La commande loginctl terminate-user <user> a fonctionné pour moi. (Remplacez <user> par votre nom d'utilisateur) Vous ne devriez probablement pas l'exécuter une fois connecté, car cela tuerait tous vos processus.
Lorsque vous vous "déconnectez" du bureau par défaut dans Ubuntu 18.04, certains processus de l'utilisateur ne sont pas terminés immédiatement, mais traînent en longueur. Ce sont (observés par un autre utilisateur):
$ ps axu | grep ^ludwig
ludwig 26508 0.3 0.2 77052 8308 ? Ss 23:32 0:00 /lib/systemd/systemd --user
ludwig 26509 0.0 0.0 261776 2968 ? S 23:32 0:00 (sd-pam)
ludwig 26691 0.2 0.3 381288 12204 ? S<l 23:32 0:00 /usr/bin/pulseaudio --start --log-target=syslog
ludwig 27352 0.0 0.0 49796 3756 ? Ss 23:33 0:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
Lorsque vous vous reconnectez avant que ces processus ne se terminent volontairement, aucune nouvelle session de connexion n'est créée, mais l'ancienne est réutilisée. C'est la raison pour laquelle la nouvelle appartenance au groupe n'est pas visible, c'est toujours la même ancienne session de connexion.
Une solution de contournement pour éviter le redémarrage consiste à attendre environ 20 secondes après la déconnexion, puis seulement après la reconnexion. Les processus se terminent entre 10 et 20 secondes après la déconnexion.
Edit: Comme indiqué dans les commentaires ci-dessous, les processus en attente ne sont parfois pas arrêtés, même en attente, et après la connexion, les appartenances aux groupes n'ont pas été mises à jour. J'ai trouvé que dans ce cas, cela aide à
ps axu | grep ^ludwig | awk '{print $2}' | xargs kill -9
Remplacez ludwig par votre nom d'utilisateur. Cela tue tous les processus qui vous appartiennent. Utilisez-le uniquement lorsque vous avez la certitude d'avoir sauvegardé toutes vos données dans tous vos programmes ouverts.
Les processus restants pour l'utilisateur après la déconnexion sont liés à systemd
usrtest 4150 4150 4150 1,7 0,1 77140 8500? Ss 22:46 0:00/lib/systemd/systemd --utilisateur
test utilisateur 4151 4150 4150 0.0 0.0 280232 3084? S 22:46 0:00 (pd-pam)
test utilisateur 4610 4610 4610 0,2 0,0 49796 3824? Ss 22:47 0:00/usr/bin/dbus-daemon --session --address = systemd: --nofork --nopidfile --systemd-activation --syslog-only
usrtest 4328 4327 4327 0,5 0,1 386100 12060? S
ces processus sont en effet lancés par systemd pour le compte de l'utilisateur.
J'ai donc fait le test suivant:
cat /etc/systemd/system/[email protected] KillMode = groupe-contrôle
systemctl --system show -p KillMode [email protected] KillMode = groupe-contrôle
après une opération de déconnexion/connexion, il semble modifier ce comportement après (encore) une nouvelle déconnexion/connexion suivant un usermod -a -G, la commande 'groups' renvoie le groupe ajouté. Je n’aime pas ça parce que si ces processus sont en attente après la déconnexion, il ya probablement une bonne raison (les opérations de fermeture semblent probables), mais ce problème semble définitivement lié à systemd.
Une solution de contournement dans le shell actuel consiste à exécuter "su" pour que le nouveau groupe ne soit pas obligé de redémarrer.
Comme je l'ai dit, cette astuce doit être appliquée à chaque shell. Ce n'est pas global.