[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re : Re: Problème avec pulseaudio



Le mercredi 23 juin 2021 à 06:39, Haricophile <haricophile@aranha.fr> a écrit :

> Le mieux ça serait de voir comment est lancé pulseaudio pour voir
>
> pourquoi il est lancé en nobody qui n'a pas de /home/nobody d'où le
>
> "nonexitent", au lieu d'être lancé sous un user. Sans
>
> rejeter totalement le bug, à mon avis c'est dans une config ou
>
> le profil de l'utilisateur (quelque chose qui a changé avec un
>
Chez moi il semble être lancé par systemd lors de l'exécution des tâches cron.daily, et plus particulièrement du script /etc/cron.daily/locate qui contient :
# run find as this user
LOCALUSER="nobody"
Ça lance le script /usr/bin/updatedb.findutils qui fait un `su nobody` ... ce qui provoque :
Jun 23 06:55:12 pbp systemd[1]: Created slice User Slice of UID 65534.
Jun 23 06:55:12 pbp systemd[1]: Starting User Runtime Directory /run/user/65534...
Jun 23 06:55:12 pbp systemd[1]: Finished User Runtime Directory /run/user/65534.
Jun 23 06:55:12 pbp systemd[1]: Starting User Manager for UID 65534...
et une tentative de lancement de pulseaudio.service pour cet utilisateur.

Pour l'UID 1000 pulseaudio se lance normalement.

Pour l'UID 0 ça donne :
Jun 23 07:09:28 pbp systemd[1951]: Condition check resulted in Sound System being skipped.

C'est dû à une ligne dans /usr/lib/systemd/user/pulseaudio.service :
ConditionUser=!root

On peut obtenir la même chose pour nobody en ajoutant :
ConditionUser=!nobody
juste en dessous.

Préalablement, pour éviter que ce soit écrasé par une mise à jour de pulseaudio :
# dpkg-divert --rename /usr/lib/systemd/user/pulseaudio.service
# cp /usr/lib/systemd/user/pulseaudio.service.distrib /usr/lib/systemd/user/pulseaudio.service

Après je ne sais pas trop à qui attribuer ce bug, est-ce que pulseaudio devrait intégrer une condition pour nobody comme pour root ? est-ce que systemd ne devrait pas lancer de "User Manager" pour nobody ? est-ce que c'est le script updatedb.findutils qui fait quelque chose d'incorrect ?

Maintenant que j'ai identifié /etc/cron.daily/locate comme source du problème, je me suis aperçu que locate n'est pas installé sur ma buster, c'est mlocate à la place...

Du coup ma solution finale :
# apt-get install mlocate locate-

Comme ça plus besoin de /nonexistant ou de diversion.


Reply to: