Ich löse erstmal die "Hausaufgabe" (eigentlich ist es ja kindisch<g>) vom Problem am 26.2. 20:50, dort ging es ja um den systemd-Teil (ps-Ausgabe und systemctl-Startproblem für pulseaudio):
Du konntest dort den user-pulseaudio.service nicht starten bzw. die Fehlermeldung des services war sinngemäß "Startversuche zu schnell hintereinander, start-limit-hit überschritten". Das war die Wirkung.
Ursache war: In der ps-Ausgabe für systemd sieht man (sollte man sehen), daß es 2/zwei /use/bin/dbus-daemon --session Prozesse gab. Es soll darf aber nur einen geben. Diese zwei (user)--session-Prozesse("Hinterhof") bewirkten nun, daß auch zweimal kurz hintereinander versucht wurde den pulseaudio.service zu starten. Was dann mit der entsprechenden Fehlermeldung(start-hit-limit) nicht erfolgte.
Auslöser dieser Situation war, das du dein XOrg (wie für minirc) mit "dbus-run-session -- startx" gestartet hast. Und dieses dbus-run-session führte zur zweiten (user)dbus-session, unter systemd ist das nicht nötig, die (user)-dbus-session wird automatisch gestartet. Ein einfaches startx unter systemd hätte also genügt.
Das war eigentlich schon alles, meine ganzen Tips sollten halt draufrauslaufen daß du siehst: Huch, da sind ja 2 --session User-Prozesse, deswegen die pulseaudio-Service-Meldung. Eine startet systemd, die andere wohl ich per meinem startx-kommando, also lasse ich die doch mal weg unter systemd.
So, zum aktuellen Stand.
Du versuchst z.Zt. ausschließlich unter systemd pulseaudio zum Laufen zu kriegen, sehe ich das richtig?
brikler jetzt hab ich den dbus-run-session entfernt, weils den eigentlich nicht braucht, und dbus-daemon --system gestartet, funktionieren tuts trotz dem nicht
Es ist definitiv nicht notwendig, den dbus-daemon --system Prozeß (die "Hauptstrasse") per Hand zu starten. Das scheint in deiner ps-Ausgabe auch nicht funktioniert zu haben, man sieht in der Zeile für PID 231 ja nicht mal das gestartete Programm(Ende der Zeile).
Ich kann dir nur den "normalen" Ablauf unter einem systemd-System nochmal zeigen, so wie es für 99% der User auch funktioniert. Ich habe rebootet um 15:29.
a) Der dbus-daemon --system Prozeß
$ journalctl --system -b -u dbus
Feb 28 15:29:06 ws01 systemd[1]: Started D-Bus System Message Bus.
...
Dieser Prozeß wird/muß von systemd gestartet. Automatisch. Immer. Und sieht in der Prozeßliste dann so aus:
dbus 600 0.0 0.0 13660 6900 ? Ss 15:29 0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
b) Nach dem Einloggen meines Users an tty1
$ journalctl --user -b
Feb 28 15:29:12 ws01 systemd[883]: Starting D-Bus User Message Bus Socket...
...
Feb 28 15:29:12 ws01 systemd[883]: Listening on Sound System.
Feb 28 15:29:12 ws01 systemd[883]: Listening on D-Bus User Message Bus Socket.
Feb 28 15:29:12 ws01 systemd[883]: Reached target Sockets.
Hier wird nun der User-Message-Bus angestoßen (dbus-daemon --session). Und zwar wird erst nur die dbus.socket Unit gestartet. Dies sorgt für das korrekte Erzeugen des Sockets (unter systemd in /run/user/UID/bus) und das korrekte Setzen der Umgebungsvaiablen DBUS_SESSION_BUS_ADDRESS.
Zu dem Zeitpunkt gibt es noch keinen /usr/bin/dbus-daemon --session Prozeß in der Prozeßliste! Dieser wird später durch die Unit dbus.service erst real gestartet. Die Unit dbus.socket triggert später dbus.service (kann man durch systemctl --user status dbus.socket dbus.service nachprüfen)
c) nachdem mein User XOrg startet
$ journalctl --user -b
...
Feb 28 15:29:16 ws01 systemd[883]: Started D-Bus User Message Bus.
Ab hier (also nach startx) taucht nun er wirkliche (user)dbus-session Prozeß in der ps-Liste auf. Das Starten von XOrg und meinem Mate-DE hat über den dbus.socket (Zugriff auf den Socket) den dbus.service ausgeführt. Was zu folgender ps-Ausgabe führt:
$ ps uax |grep dbus
dbus 600 0.0 0.0 13828 7044 ? Ss 15:29 0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
gerhard 921 0.0 0.0 13516 6764 ? Ss 15:29 0:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
Also ein --system dbus-Prozeß und genau ein --session dbus-Prozeß. Das alles macht systemd automatisch.
Und ab hier funktioniert dann auch pulseaudio, was übrigens ebenfalls über die Reihenfolge pulseaudio.socket->pulseaudio.service aktiviert wird. Kann mit:
$ systemctl --user status pulseaudio.socket pulseaudio
nachvollzogen werden.
Damit pulseaudio funktionieren kann braucht es - wie schon mehrfach erwähnt, und oben anhand meines Systems dokumentiert - eben den:
dbus-daemon --system Prozeß
dbus-daemon --session Prozeß (genau einen!)
Wenn das bei dir nun unter systemd nicht ebenso funktioniert:
Dann mußt du wirklich nochmal explizit nachprüfen, ob du irgendwelche systemd-Units für dbus und pulseaudio (auch die *.socket Units) maskiert, verändert hast. Oder Configs (inkl. deiner User-Shell-rc/profile) durch das parallel vorhandene (aber nicht genutzte minirc) dem Ablauf unter systemd stören würden.
Du solltest ggf. auch mal ein komplettes Bootlog (journalctl --system -b) auf einen Paste-Server hochladen und den Link hier posten. Das Bootlog am besten von nach deinem Anmelden/Starten von XOrg und wenn das pulseaudio-Problem auftritt.
Das User-Journal vom gleichen Vorgang (journalctl --user -b) wäre dann ggf. auch hifreich.
Und: ich an deiner Stelle würde mir in einer virtuellen Maschine ein funktionierendes Archlinux mit "purem" systemd (inkl. XOrg/Windowmanager) installieren. Wenn du das unverändert (also keine deiner Konfigs, kein minirc/busybox/etc.) parallel laufen hast, dann kannst du das als "Referenzsystem" nutzen. Um ggf. zu sehen: wo hakt es denn aktuell bei meinem richtigen System (was ist ggf. anders konfiguriert). Und beim Umstellen von systemd nach minirc, da wird sowas ebenfalls nützlich sein um einfach nochmal nachzuprüfen: Was macht die funktionierende Referenz anders als ich, was fehlt evtl., was ist zuviel...
