| Summary: | startx causes permission problems with systemd/pulseaudio because the X server's TTY differs from the one startx was called from | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | zzz <e> |
| Component: | Current packages | Assignee: | Gentoo systemd Team <systemd> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | bkohler, franz.trischberger, x11 |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=521392 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
$ cat ~/.xserverrc #!/bin/bash exec /usr/bin/X -nolisten tcp vt$XDG_VTNR "$@" ### AFAIK Fedora has put something like this into system xserverrc (In Gentoo it's /etc/X11/xinit/xserverrc - you can edit that file too, in the same way, to get it done for every user). I don't know if it breaks non-systemd-setups. @x11, what do you think? xserverrc's your domain :). I think this issue is bigger than just PA, I've read time and time again that startx is known to not properly "hook into" logind unless you modify it to start on the same TTY so you reuse the console login's logind session. New approach: XDG_VTNR is not set with openrc/consolekit, only with systemd/logind. So check for its existence:
$ cat .xserverrc
#!/bin/bash
if [ ! -z ${XDG_VTNR+x} ]
then
X_VT_ARG="vt$XDG_VTNR"
else
X_VT_ARG=""
fi
exec /usr/bin/X -nolisten tcp $X_VT_ARG "$@"
> if [ ! -z ${XDG_VTNR+x} ]
?
if [ $XDG_VTNR ]
Just curious, why not that?
[ $XDG_VTNR ] && VT_ARG=vt$XDG_VTNR || VT_ARG=
if [ $XDG_VTNR ]
then
VT_ARG=vt$XDG_VTNR
else
VT_ARG=
fi
[ $foo ]
is a bashism. Please use
[ -n "${foo}" ]
:).
(In reply to Michał Górny from comment #6) > [ $foo ] > > is a bashism. Please use > > [ -n "${foo}" ] > > :). Is it secure to check a non-existant variable for emptyness? I simply googled for "bash variable exists" (my Bash is as good as my Swedish, so please forgive me ;)) Yes, assuming that we want to treat empty & unset the same way.
BTW some ancient script go even further:
if test x"$foo" = x""
then
...
fi
but that's rather unnecessary in any shell we have in Gentoo.
@ Michal thx! In the meantime I tried my changes with both openrc and systemd. I have no issues to get my awesome WM started with startx. systemd uses the current VT, openrc starts at VT7. But I am not using pulseaudio, but I assume it works. This has already been fixed in x11-apps/xinit-1.3.3-r1. See bug 451956. *** This bug has been marked as a duplicate of bug 451956 *** |
For permissions to work correctly with pulseaudio (with systemd/logind), the X session has to be started on the same tty. The only documentation I can find on this is from the pulseaudo gentoo wiki page, which states ``For ConsoleKit/Systemd Logind managed permissions to be respected no one may be part of the audio group (not even even the user pulse). Remove any and all users from the audio group''. However that's not enough, you have to start the X session on the same tty or else it won't work and you will have no access to audio. Working around it by adding your user to the audio group is not ideal because if you're still using the audio device and switch users then audio won't work for the other usr. There's some other issues with that too. The problem is that when you start it with the startx command on gentoo (with systemd), it will start the X session on another tty. By default the startx command on Fedora will start the X session on the same tty. I think this should probably be the default behavoir on gentoo at least with systemd. For now, I've added this to my ~/.bashrc to work around it startx() { setsid startx -- vt$(fgconsole) } Please forgive me if there is just some service that I need to start for this to work properly.