[arch-general] [Bad fix?] was Re: No user sound - only root has access alsamixer on virtualbox?

David C. Rankin drankinatty at suddenlinkmail.com
Mon Feb 3 10:05:31 EST 2014


On 02/02/2014 04:22 PM, Armin K. wrote:
>>    According to
>> https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture (footnote
>> [1] under Installation) sound access was provided to users via Consolekit in the
>> past. Consolekit is no longer part of Arch. I have kept basic build of TDE for
>> Arch totally reliant on Arch packages, so I would like to solve the sound
>> problem in the proper way so that this desktop is a seamless addition to Arch.
>> What is the best approach to finding a solution to this sound issue?
>>
> 
> You shouldn't need to have user member of any group that granted access to the
> any kind of hardware nowadays. That's handled by logind, which is a replacement
> for ConsoleKit.
> 
> But, if you start your DE via .xinitrc, you need to make xserver start on the
> same VT in order to preserve valid systemd session. Also, you should have a user
> dbus daemon started, as I already pointed out.
> 
> If you are starting your DE via some kind of Display Manager, and given that it
> uses PAM, its PAM file need to contain systemd pam file in session section,
> unless you include system files.
> 
> https://wiki.archlinux.org/index.php/Xinitrc#Getting_started - Scroll down to
> the note right before "Configuration"
> 
> https://wiki.archlinux.org/index.php/General_Troubleshooting#Session_permissions

OK,

  Now we are getting somewhere. Trinity desktop tdm.service is started by
systemd on boot. tdm is an updated kde3/kdm desktop manager. tdm.service contains:

[Unit]
Description=TDE Display Manager
After=systemd-user-sessions.service

[Service]
ExecStart=/opt/trinity/bin/tdm

[Install]
Alias=display-manager.service

  On installation trinity also creates and installs a pam file in pam.d
containing the following:

/etc/pam.d/trinity
#%PAM-1.0

#auth       required     pam_securetty.so
auth       requisite    pam_nologin.so
auth       include      system-local-login
account    include      system-local-login
session    include      system-local-login

  On login, dbus and pulseaudio are started from /etc/X11/xinit/xinitrc.d. The
two files started are:

30-dbus
pulseaudio

  All of this looks exactly correct for what is described in
https://wiki.archlinux.org/index.php/General_Troubleshooting#Session_permissions. Except
for the response from loginctl. Checking loginctl I do not get Remote=no and
Active=yes as suggested on the page, instead I get:

08:29 valhalla:~> loginctl show-session $XDG_SESSION_ID
NAutoVTs=6
KillExcludeUsers=root
KillUserProcesses=no
IdleHint=yes
IdleSinceHint=0
IdleSinceHintMonotonic=0
InhibitDelayMaxUSec=5s
HandlePowerKey=poweroff
HandleSuspendKey=suspend
HandleHibernateKey=hibernate
HandleLidSwitch=suspend
IdleAction=ignore
IdleActionUSec=30min
PreparingForShutdown=no
PreparingForSleep=no

  So, according to the Troubleshooting section -- If it does not [contain
Remote=no and Active=yes], make sure that X runs on the same tty where the login
occurred.

  Here is where I need help. Systemd is doing the starting, so how can I make
sure that X runs on the same tty where the login occurred? Where/how do I
specify what vt X is running on?

-- 
David C. Rankin, J.D.,P.E.


More information about the arch-general mailing list