Wie verhindere ich, dass Pulseaudio abstürzt, wenn ich eine virtuelle Maschine von VirtualBox starte?

Wie verhindere ich, dass Pulseaudio abstürzt, wenn ich eine virtuelle Maschine von VirtualBox starte?

/!\Update 2 Unten - Pulseaudio ist nicht der Übeltäter, libpam-systemd schon/!\

Mir ist aufgefallen, dass gksu virtualbox %UPulseaudio jedes Mal abstürzt, wenn ich eine virtuelle Maschine von VirtualBox aus starte. Dann erhalte ich sofort diesen Fehler von VirtualBox:

No audio devices could be opened. Selecting the NULL audio backend
with the consequence that no sound is audible.

Und

HostAudioNotResponding

Außerdem gibt VMware Workstation an, dass kein Ton wiedergegeben wird, da dieser Fehler aufgetreten ist:

/dev/dsp kann nicht gefunden werden.

Das stimmt, da ich diese Datei nicht einmal finden kann.

Das Syslog sagt allerdings nicht viel über den Absturz aus:

May 31 18:18:58 HostName pulseaudio[3466]: [autospawn] core-util.c: Failed to create secure directory (/run/user/1000/pulse): Permission denied
May 31 18:18:58 HostName pulseaudio[3466]: [autospawn] lock-autospawn.c: Cannot access autospawn lock.
May 31 18:18:58 HostName pulseaudio[3466]: [pulseaudio] main.c: Failed to acquire autospawn lock
May 31 18:18:59 HostName pulseaudio[3471]: [autospawn] core-util.c: Failed to create secure directory (/run/user/1000/pulse): Permission denied
May 31 18:18:59 HostName pulseaudio[3471]: [autospawn] lock-autospawn.c: Cannot access autospawn lock.
May 31 18:18:59 HostName pulseaudio[3471]: [pulseaudio] main.c: Failed to acquire autospawn lock
May 31 18:18:59 HostName pulseaudio[3473]: [autospawn] core-util.c: Failed to create secure directory (/run/user/1000/pulse): Permission denied
May 31 18:18:59 HostName pulseaudio[3473]: [autospawn] lock-autospawn.c: Cannot access autospawn lock.
May 31 18:18:59 HostName pulseaudio[3473]: [pulseaudio] main.c: Failed to acquire autospawn lock
May 31 18:18:59 HostName pulseaudio[3475]: [autospawn] core-util.c: Failed to create secure directory (/run/user/1000/pulse): Permission denied
May 31 18:18:59 HostName pulseaudio[3475]: [autospawn] lock-autospawn.c: Cannot access autospawn lock.
May 31 18:18:59 HostName pulseaudio[3475]: [pulseaudio] main.c: Failed to acquire autospawn lock
May 31 18:18:59 HostName pulseaudio[3478]: [autospawn] core-util.c: Failed to create secure directory (/run/user/1000/pulse): Permission denied
May 31 18:18:59 HostName pulseaudio[3478]: [autospawn] lock-autospawn.c: Cannot access autospawn lock.
May 31 18:18:59 HostName pulseaudio[3478]: [pulseaudio] main.c: Failed to acquire autospawn lock
May 31 18:19:00 HostName pulseaudio[3483]: [autospawn] core-util.c: Failed to create secure directory (/run/user/1000/pulse): Permission denied
May 31 18:19:00 HostName pulseaudio[3483]: [autospawn] lock-autospawn.c: Cannot access autospawn lock.
May 31 18:19:00 HostName pulseaudio[3483]: [pulseaudio] main.c: Failed to acquire autospawn lock
May 31 18:19:09 HostName pulseaudio[3488]: [autospawn] core-util.c: Failed to create secure directory (/run/user/1000/pulse): Permission denied
May 31 18:19:09 HostName pulseaudio[3488]: [autospawn] lock-autospawn.c: Cannot access autospawn lock.
May 31 18:19:09 HostName pulseaudio[3488]: [pulseaudio] main.c: Failed to acquire autospawn lock
May 31 18:19:09 HostName pulseaudio[3490]: [autospawn] core-util.c: Failed to create secure directory (/run/user/1000/pulse): Permission denied
May 31 18:19:09 HostName pulseaudio[3490]: [autospawn] lock-autospawn.c: Cannot access autospawn lock.
May 31 18:19:09 HostName pulseaudio[3490]: [pulseaudio] main.c: Failed to acquire autospawn lock
May 31 18:19:17 HostName pulseaudio[3496]: [autospawn] core-util.c: Failed to create secure directory (/run/user/1000/pulse): Permission denied
May 31 18:19:17 HostName pulseaudio[3496]: [autospawn] lock-autospawn.c: Cannot access autospawn lock.
May 31 18:19:17 HostName pulseaudio[3496]: [pulseaudio] main.c: Failed to acquire autospawn lock
May 31 18:19:18 HostName pulseaudio[3498]: [autospawn] core-util.c: Failed to create secure directory (/run/user/1000/pulse): Permission denied
May 31 18:19:18 HostName pulseaudio[3498]: [autospawn] lock-autospawn.c: Cannot access autospawn lock.
May 31 18:19:18 HostName pulseaudio[3498]: [pulseaudio] main.c: Failed to acquire autospawn lock
May 31 18:20:28 HostName pulseaudio[1847]: [pulseaudio] protocol-native.c: Denied access to client with invalid authorization data.

Da steht nur, dass Pulseaudio nicht neu gestartet werden kann, da es /run/user/1000/pulse/den berüchtigten Bug hat, dass es root gehört. Was ich einfach behoben habe mit:

chown standardUser /run/user/1000/pulse/ && chgrp standardUser /run/user/1000/pulse/

Aber immer noch kein Hinweis darauf, was den Absturz von Pulseaudio verursacht haben könnte.

Die Frage ist also: Warum stürzt Pulseaudio ab und wie kann dies verhindert werden?

Alles wurde auf einem aktualisierten Debian 8.7 mit der Standard-KDE-Desktopumgebung durchgeführt.


Aktualisierung 1:

Nach vielem Ausprobieren und Raten habe ich durch Bearbeiten der Datei /etc/pluse/default.pa einige Verbesserungen erzielt.

Durch Aktivieren dieser Pulseaudio-Module: - module-alsa-sink - module-oss device="/dev/dsp" sink_name=output source_name=input

Durch die Aktivierung module-ossmit diesen Optionen wird die Datei /dev/dsp aktiviert und verhindert, dass VMware Workstation seinen Fehler auslöst.

Führt einen Modeprobe von: snd-pcm-oss durch

Und deaktivieren Sie diese Module:

  • Modul-Esound-Protokoll-Unix
  • Modul-Suspend-on-Leerlauf

Es gibt fast überhaupt keine Fehler (ich habe aber immer noch den VirtualBox-Fehler und den berüchtigten Pulse-Ordner, der dem Root gehört), außer diesem, den ich vom Syslog erhalten habe:

May 31 22:09:11 HostName pulseaudio[3376]: Trying resume...
May 31 22:09:11 HostName pulseaudio[3376]: open '/dev/snd/pcmC0D0p' failed (-16)
May 31 22:09:11 HostName pulseaudio[3376]: Error opening PCM device front:0: Device or resource busy
May 31 22:09:11 HostName pulseaudio[3376]: Using generic matrix remapping

Und dieses, seit ich Pulseaudio manuell mit „pulseaudio -vvvv“ gestartet habe:

I: [pulseaudio] client.c: Created 1 "Native client (UNIX socket client)"
D: [pulseaudio] protocol-native.c: Protocol version: remote 29, local 29
I: [pulseaudio] protocol-native.c: Got credentials: uid=0 gid=0 success=0
W: [pulseaudio] protocol-native.c: Denied access to client with invalid authorization data.
I: [pulseaudio] client.c: Freed 1 "Native client (UNIX socket client)"
I: [pulseaudio] protocol-native.c: Connection died.

Ich kann immer noch nicht verstehen, warum der Fehler „/dev/snd/pcmC0D0p“ auftritt und warum es sich anscheinend um ein Berechtigungsproblem handelt.

Abgesehen von Syslog und dem Ausführen von Pulseaudio im Ultra-Ausführlichen-Modus weiß ich nicht, wie ich verfolgen kann, was mit Pulseaudio passiert.

Gibt es eine Möglichkeit, weitere Informationen zu diesem Absturz bereitzustellen?


Aktualisierung 2

Zusätzlich zu dem, was ich in Update 1 gemacht habe:

/etc/pulse/default.pa wurde angehängt:

module-native-protocol-unix auth-anonymous=1
module-native-protocol-tcp auth-anonymous=1 auth-ip-acl=127.0.0.1

/etc/pulse/client.conf wurde angehängt:

default-server = 127.0.0.1

modprobe snd-pcm-osswird noch benötigt.

Alles, was mit Pulseaudio zu tun hatte, funktionierte, selbst VMware beschwerte sich nicht darüber, dass /dev/dsp nicht funktionierte (funktioniert nur mit modprobe snd-pcm-oss). Pulseaudio -vvvv oder /var/log/syslog/ haben keine Fehler gefunden.

Leider fehlt immer noch der Ton, während Pulseaudio perfekt funktioniert.

Darüber hinaus habe ich auch versucht, Pulseaudio im Systemmodus auszuführen, aber es wurde nicht besser und das Problem war das gleiche.

Das Hauptproblem schien also darin zu liegen, dass /run/user/1000/pulse von Root in Besitz genommen wurde, was bedeutet, dass das eigentliche Problem dieser berüchtigte Bug war.

Nach einigen Recherchen fand ich heraus, dass libpam-systemd das verursacht. Dies ist ein bekannter Fehler, den Debian von Systemd bekommen hat und der für Debian Testing (Stretch) und Experimental gemeldet wurde; aber überhaupt nicht für Stable:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732209

http://forums.debian.net/viewtopic.php?f=10&t=110035

https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=libpam-systemd

Bezüglich des 2. Links bestätige ich auch das „gksu gedit“-Problem, für das ich den gleichen Workaround angewendet habe.

Das Problem scheint ungelöst, zumindest bis die Betreuer von Debian Stable libpam-systemd aktualisieren.

Andererseits habe ich ihnen einen Fehlerbericht geschickt. Außerdem empfehle ich Leuten, die ebenfalls mit diesem Fehler konfrontiert sind, ihn noch einmal zu melden, damit sie eine echte Bestätigung erhalten.

Außerdem würde ich mich über jede Lösung freuen, wenn jemand in der Zwischenzeit weiß, wie man diesen Fehler behebt. Dazu gehört auch das Neukompilieren von libpam-systemd als Deb (da ich nicht weiß, wie man das richtig auf die Debian-Art macht), jeder Hinweis ist willkommen.

Antwort1

Ich kann den /dev/snd/pcmC0D0pFehler erklären: Dies ist ein ALSA-Gerät. Wenn Pulseaudio startet, öffnet es alle ALSA-Geräte, die es finden kann. Da ALSA-Hardwaregeräte nicht gemeinsam genutzt werden können und nur einmal geöffnet werden können, gibt das Gerät beim nächsten Versuch, es zu öffnen, einen „Beschäftigt“-Fehler aus.

Wenn Sie also Pulseaudio in Ihrer Hauptumgebung ausführen und Virtualbox so konfiguriert haben, dass Soundgeräte nur „durchgereicht“ werden, verwendet das Haupt-Pulseaudio das Gerät, was bei Virtualbox nicht der Fall ist.

Wenn virtualbux das Soundgerät emuliert, läuft in der Virtualbox etwas anderes, das es öffnet, beispielsweise eine zweite Pulseaudio-Instanz. Verwenden Sie lsofund, psum herauszufinden, welche.

Modprobing snd-pcm-osshilft da nicht wirklich weiter: Das ist die OSS-Emulationsschicht in ALSA, die stellt /dev/dspetc. bereit, was nur ein Alias /dev/snd/pcmC0D0p​​mit einer anderen API ist. Und wenn man beides in Pulseaudio aktiviert module-alsa-sink, module-ossöffnet Pulseaudio beides fröhlich, was natürlich Blödsinn ist. Also den OSS-Kram wieder deaktivieren, das ist nicht die Lösung.

Meiner Erfahrung nach pulseaudio -vvvvreicht aus, um Ihnen eine Vorstellung davon zu geben, was tatsächlich schief läuft. Wenn es tatsächlich zu einem Absturz kommt, wie bei einer „Segmentierungsverletzung“ usw., sollte Ihnen die Verwendung straceoder der Start mit gdb, wenn möglich auf einer Version mit Debugsymbolen, wieder eine Vorstellung davon geben, was tatsächlich schief läuft.

Ich vermute, dass Ihre Konfiguration irgendwo einen Haken hat, aber ich habe nicht genügend Informationen, um das herauszufinden.

verwandte Informationen