trouver l'unité systemd «propriétaire» d'un processus démon en cours d'exécution

25

Pour déboguer un problème JACK / Pulseaudio, je veux comprendre quand et pourquoi le démon pulseaudio est démarré par systemd (sur Fedora).

En utilisant:

$ ps -o'pid,ppid,args' `pgrep pulse`

Je vois que le démon pulseaudio est démarré par systemd (pid = 1)

 PID  PPID COMMAND
2738     1 /usr/bin/pulseaudio --start

Cependant, je n'ai pas pu trouver de fichier d'unité sur mon système contenant pulseaudioou même juste pulse.

Mes questions spécifiques sont:

A) Existe-t-il un moyen de déterminer l'unité systemd qui a provoqué la création d'un processus spécifique (dans mon exemple de sortie, le processus 2738, le démon PA)?

B) Existe-t-il des approches alternatives pour savoir quelle chaîne de dépendance à l'unité ou autres paramètres de systemd a entraîné l'invocation de /usr/bin/pulseaudio --start?

fedora systemd pulseaudio

— neradis
source

24

A) Existe-t-il un moyen de déterminer l'unité systemd qui a provoqué la création d'un processus spécifique (dans mon exemple de sortie, le processus 2738, le démon PA)?

Sûr. Vous pouvez exécuter systemctl status <pid>et systemd vous trouvera l'unité qui contient ce PID. Par exemple, sur mon système, je trouve un dnsmasqprocessus:

# ps -fe | grep dnsmasq
nobody   18834  1193  0 Aug25 ?        00:00:10 /usr/sbin/dnsmasq ...

Qui a commencé?

# systemctl status 18834
● NetworkManager.service - Network Manager
   Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2015-08-25 11:07:40 EDT; 1 day 21h ago
 Main PID: 1193 (NetworkManager)
   Memory: 1.1M
   CGroup: /system.slice/NetworkManager.service
           ├─ 1193 /usr/sbin/NetworkManager --no-daemon
           ├─ 1337 /sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper -pf /var/run/dhclient-wlp3s0....
           ├─18682 /usr/libexec/nm-openvpn-service
           ├─18792 /usr/sbin/openvpn --remote ovpn-phx2.redhat.com 443 tcp --nobind --dev redhat --de...
           └─18834 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --...

J'ai aussi un pulseaudioprocessus:

# ps -fe | grep pulseaudio
lars      2948     1  0 Aug25 ?        00:06:20 /usr/bin/pulseaudio --start

Courir systemctl status 2948, je vois:

● session-3.scope - Session 3 of user lars
   Loaded: loaded (/run/systemd/system/session-3.scope; static; vendor preset: disabled)
  Drop-In: /run/systemd/system/session-3.scope.d
           └─50-After-systemd-logind\x2eservice.conf, 50-After-systemd-user-sessions\x2eservice.conf, 50-Description.conf, 50-SendSIGHUP.conf, 50-Slice.conf
   Active: active (running) since Tue 2015-08-25 11:09:23 EDT; 1 day 21h ago
   CGroup: /user.slice/user-1000.slice/session-3.scope

Cela m'indique que a pulseaudioété démarré à partir de ma session de connexion au bureau, plutôt que explicitement via systemd.

— larsks
source

1

Je voulais trouver un moyen de scénariser cela. systemctla une --propertyoption pour sélectionner les propriétés d'unité à afficher, mais malheureusement cela ne fonctionne qu'avec shownon status, et showne fonctionne pas avec les PID. Le mieux que j'ai pu trouver est:systemctl status -n0 $PID 2>/dev/null | head -n1 | awk '{print $2}'

— Neil Mayhew

@NeilMayhew Voir la ps -o unitréponse de Lukáš. En supposant que vous utilisez un système moderne et que cela fonctionne, c'est une belle chose.

— vu

6

Au fait, vous pouvez demander à ps d'afficher l'unité systemd correspondante.

[lnykryn@notas]$ ps -o'pid,ppid,args,unit' `pgrep pulse`
  PID  PPID COMMAND                     UNIT
 1345     1 /usr/bin/pulseaudio --start session-1.scope

— Lukáš Nykrýn
source

Cela ne fonctionne pas pour moi et je remarque que man ps"si la prise en charge de systemd a été incluse". Je suppose donc que cela dépend du système.

— Neil Mayhew

Impressionnant! Et ce serait encore mieux avec l' ps -C CMDoption sous-utilisée , par exemple ps -o pid,args,unit -C pulseaudio.

— vu

4

Remarque, un processus ayant un PPID parent de 1 ne signifie pas qu'il a été créé par systemd. Tout processus qui perd son processus parent est automatiquement réaffecté au parent 1.

Vous pouvez voir la hiérarchie des processus systemd avec

systemctl status

ce qui me montre entre autres choses (édité):

CGroup: 
|-1 /usr/lib/systemd/systemd --system --deserialize 17
|-system.slice
`-user.slice
  `-user-1000.slice
    |-session-66.scope
    | |-4108 /bin/dbus-launch --autolaunch ...
    | |-4109 /bin/dbus-daemon --fork ...
    | `-5985 /usr/bin/pulseaudio --start --log-target=syslog

— meuh
source

Merci d'avoir souligné mon erreur sur PPID == 1. En fait, je le savais déjà et je l'ai juste oublié en pensant à cette question.

— neradis