Auffinden, ob die Systemeinheit einen laufenden Daemon-Prozess besitzt

24

Um ein JACK / Pulseaudio-Problem zu beheben, möchte ich verstehen, wann und warum der pulseaudio-Daemon von systemd (unter Fedora) gestartet wird.

Verwenden von:

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

Ich sehe, dass der pulseaudio-Daemon von systemd gestartet wird (pid = 1)

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

Ich konnte jedoch keine Unit-Datei auf meinem System finden, die eine pulseaudiooder auch nur eine enthält pulse.

Meine spezifischen Fragen sind:

A) Gibt es eine Möglichkeit, die Systemeinheit zu bestimmen, die die Erstellung eines bestimmten Prozesses verursacht hat (in meiner Beispielausgabe Prozess 2738, der PA-Dämon)?

B) Gibt es alternative Ansätze, um herauszufinden, welche Einheitenabhängigkeitskette oder andere Einstellungen von systemd zum Aufruf von geführt haben /usr/bin/pulseaudio --start?

fedora systemd pulseaudio

— Neradis
quelle

23

A) Gibt es eine Möglichkeit, die Systemeinheit zu bestimmen, die die Erstellung eines bestimmten Prozesses verursacht hat (in meiner Beispielausgabe Prozess 2738, der PA-Dämon)?

Sicher. Sie können ausführen systemctl status <pid>und systemd findet die Einheit, die diese PID enthält. Zum Beispiel finde ich auf meinem System einen dnsmasqProzess:

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

Wer hat damit angefangen?

# 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 --...

Ich habe auch einen pulseaudioProzess:

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

Laufen systemctl status 2948sehe ich:

● 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

Dies sagt mir, dass der pulseaudioStart von meiner Desktop-Anmeldesitzung statt explizit über systemd erfolgte.

— larsks
quelle

1

Ich wollte einen Weg finden, dies zu schreiben. systemctlEs gibt eine --propertyOption zum Auswählen der anzuzeigenden Einheiteneigenschaften. Leider funktioniert dies nur mit " showNicht" statusund shownicht mit "PIDs". Das Beste, was ich mir einfallen lassen konnte, war:systemctl status -n0 $PID 2>/dev/null | head -n1 | awk '{print $2}'

— Neil Mayhew,

@NeilMayhew Siehe ps -o unitAntwort von Lukáš. Vorausgesetzt, Sie arbeiten auf einem modernen System und es funktioniert, ist es eine schöne Sache.

— Rsaw

6

Übrigens können Sie ps bitten, die entsprechende Systemeinheit anzuzeigen.

[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
quelle

Dies funktioniert bei mir nicht und ich stelle fest, man psdass "wenn systemd-Unterstützung enthalten ist". Ich gehe also davon aus, dass es systemabhängig ist.

— Neil Mayhew

Genial! Und wäre noch besser mit der nicht ausgenutzten ps -C CMDOption, z ps -o pid,args,unit -C pulseaudio.

— Rsaw

4

Beachten Sie, dass ein Prozess mit einer übergeordneten PPID von 1 nicht bedeutet, dass er von systemd erstellt wurde. Jedem Prozess, der seinen übergeordneten Prozess verliert, wird automatisch der übergeordnete Prozess 1 zugewiesen.

Sie können die Hierarchie der systemd Prozesse mit sehen

systemctl status

das zeigt für mich unter anderem (bearbeitet):

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
quelle

Vielen Dank, dass Sie auf meinen Irrtum in Bezug auf PPID == 1 hingewiesen haben. Eigentlich wusste ich das schon und habe es einfach vergessen, als ich über diese Frage nachdachte.

— Neradis