if you do export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/500/bus and then do startx does it work?
Maybe start grepping through things for dbus?
Edit … as a suggestion from your home directory.. might be noisy
grep -rsiI dbus * .* .config /etc --exclude=*history*
It is not necessarily a config file under the user’s home directory. It could be coded in the OS somewhere that “system” accounts get dbus sockets under /tmp while normal user accounts get dbus sockets under /run/user.
that would be a bug, because programs should honor the settings in /etc/login.defs like systemd does. ( assuming UID_MIN 500 is in /etc/login.defs )
why does the new user get assigned uid 1002 and not 50x?
does your system define UID_MIN 1000 or 500?
grep '^\(SYS_\)\?UID_\(MIN\|MAX\)' /etc/login.defs
update: should not matter though, I created a sys user and audio works
$ id
uid=500(sysuser) gid=500(sysuser) groups=500(sysuser) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
$ env | grep -E "XDG_RUNTIME_DIR|DBUS_SESSION"
XDG_RUNTIME_DIR=/run/user/500
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/500/bus
$ ll /run/user/500/pipewire-0*
srw-rw-rw-. 1 sysuser sysuser 0 Jul 3 22:42 /run/user/500/pipewire-0
-rw-r-----. 1 sysuser sysuser 0 Jul 3 22:42 /run/user/500/pipewire-0.lock
srw-rw-rw-. 1 sysuser sysuser 0 Jul 3 22:42 /run/user/500/pipewire-0-manager
-rw-r-----. 1 sysuser sysuser 0 Jul 3 22:42 /run/user/500/pipewire-0-manager.lock
$ ll /run/user/500/pulse/
total 4
srw-rw-rw-. 1 sysuser sysuser 0 Jul 3 22:42 native
-rw-r--r--. 1 sysuser sysuser 7 Jul 3 22:43 pid
$ paplay -v /usr/share/sounds/alsa/Front_Center.wav
Opening a playback stream with sample specification 's16le 1ch 48000Hz' and channel map 'mono'.
Connection established.
Stream successfully created.
Buffer metrics: maxlength=4194304, tlength=192000, prebuf=190082, minreq=1920
Using sample spec 's16le 1ch 48000Hz', channel map 'mono'.
Connected to device alsa_output.pci-0000_01_00.1.hdmi-stereo (index: 171, suspended: no).
Stream started.
Playback stream drained.: 19826 usec.
Draining connection to server.
$ grep '^\(SYS_\)\?UID_\(MIN\|MAX\)' /etc/login.defs
UID_MIN 500
UID_MAX 60000
I don’t know why the new user got id 1002, but it doesn’t seem relevant.
nothing for SYS_UID_MIN and SYS_UID_MAX ?
I thought of that, but /run/user/500 doesn’t actually exist before I start X, only after.
I’ve also been grepping ~/.config and /etc but I haven’t found anything.
I’ve tried moving .config and logging in, but that didn’ t work either.
Anything in .profile, .bashrc etc ?
Are there any .rpmnew or .rpmsave files in /etc?
That shouldn’t matter for exporting a variable or am I misunderstanding?
Nothing relevant in .bashrc or .profile.
There are plenty of .rpmnew files in /etc:
adjtime.rpmnew exports.rpmnew hosts.rpmnew krb5.conf.rpmnew ld.so.conf.rpmnew login.defs.rpmnew nsswitch.conf.rpmnew profile.rpmnew sensors3.conf.rpmnew subgid.rpmnew sysctl.conf.rpmnew
drirc.rpmnew ggz.modules.rpmnew inittab.rpmnew ldap.conf.rpmnew libuser.conf.rpmnew my.cnf.rpmnew printcap.rpmnew rpc.rpmnew shells.rpmnew subuid.rpmnew yum.conf.rpmnew
Personally, I have MERGE="vimdiff" set in /etc/environment and I make it a habit to run rpmconf -a[1] after every dnf update to deal with those .rpmnew files as soon as they appear. Vimdiff has a bit of a learning curve, but there are plenty of tutorials online.
Not having merged the login.defs updates in the past might have something to do with the problem you are seeing now.
Press m to activate vimdiff from rpmconf. After manually merging the updates with vimdiff, I usually use s from rpmconf to skip further handling of the .rpmnew file and then go back and rename the .rpmnew file(s) to .original so that I have something to compare my changes against in the future. ↩︎
..Futzing around in a F44 KDE VM I was able to work around this .. .
before you startx …
systemctl start user@500.service
then
startx
If that works you can do
sudo loginctl enable-linger 500
sudo systemctl enable user@500.service --now
To make it permanent ..
You should probably research enabling linger on a user/system before making this change.
I does look like this only impacts starting from the command line.
If that’s the case, then launching startx with systemd-run --scope --user startx might also work. Maybe you could set that as an alias to work around the problem. See the “screen” example near the end of the systemd-run man page for more details.
send the status of the following systemctl sound services
systemctl --user status pipewire-pulse
systemctl --user status pipewire-session-manager
systemctl --user status wireplumber
That did not work. I got asked to authenticate as root. I did, but after that there was no change.
Did not work. I got a message about not being able to connect to the bus.
Workaround found: I login on the tty, run “dbus-launch”, export the variables, then run startx.
Running “dbus-launch startx” does not work.
I get:
Failed to connect to user scope bus via local transport: No such file or directory
UPDATE: that worked once, but it isn’t working every time.
I replaced login.defs with login.defs.rpmnew but it didn’t solve the problem. BTW the login.defs.rpmnew is years old, not from the f44 upgrade.
Success!! I finally figured it out. It is a problem with the uid being 500. Someone else had this problem: https://utcc.utoronto.ca/\~cks/space/blog/linux/Systemd258UsersAndSessions
That page didn’t have a solution, but Google told me to put this in /var/lib/AccountsService/users/username:
[User]
SystemAccount=false
and that worked!!