Como preservar a sessão de logind no Arch Linux?

2

Eu obtive áudio trabalhando no Arch Linux sem problemas ontem, mas em algum momento ele parou de funcionar novamente:

$ alsamixer 
cannot open mixer: No such file or directory
$ vlc foo.mp4
...
[0x7f1388006be8] alsa audio output error: cannot open ALSA device "default": No such file or directory

alsamixer é executado como root , portanto, parece ser um problema de permissão. Todos os dispositivos de áudio são de propriedade de root:audio :

$ ls -l /dev/snd
total 0
drwxr-xr-x 2 root root       80 Aug  6 22:54 by-path
crw-rw---- 1 root audio 116,  7 Aug  6 22:54 controlC0
crw-rw---- 1 root audio 116, 10 Aug  6 22:54 controlC1
crw-rw---- 1 root audio 116,  6 Aug  6 22:54 hwC0D0
crw-rw---- 1 root audio 116,  9 Aug  6 22:54 hwC1D0
crw-rw---- 1 root audio 116,  5 Aug  6 22:54 pcmC0D0c
crw-rw---- 1 root audio 116,  4 Aug  6 22:54 pcmC0D0p
crw-rw---- 1 root audio 116,  3 Aug  6 22:54 pcmC0D1p
crw-rw---- 1 root audio 116,  2 Aug  6 22:54 pcmC0D2c
crw-rw---- 1 root audio 116,  8 Aug  6 22:54 pcmC1D3p
crw-rw---- 1 root audio 116,  1 Aug  6 22:54 seq
crw-rw---- 1 root audio 116, 33 Aug  6 22:54 timer
$ getfacl /dev/snd/*
getfacl: Removing leading '/' from absolute path names
# file: dev/snd/by-path
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

# file: dev/snd/controlC0
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/controlC1
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/hwC0D0
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/hwC1D0
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/pcmC0D0c
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/pcmC0D0p
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/pcmC0D1p
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/pcmC0D2c
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/pcmC1D3p
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/seq
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/timer
# owner: root
# group: audio
user::rw-
group::rw-
other::---

Eu sou não no grupo audio , como recomendado pelo ALSA instruções :

$ groups
wheel users

Uma discussão me indicou um explicação de por que adicionar o grupo é desnecessário e às vezes prejudicial. De lá, os grupos de usuários informavam

None of these groups is needed for standard desktop permissions like sound, 3D, printing, mounting, etc. as long as the logind session isn't broken.

Seguindo as instruções para a solução de problemas de permissão de sessão , eu finalmente encontrei uma discrepância - ela diz que a saída de loginctl show-session $XDG_SESSION_ID deve conter Remote=no e Active=yes , mas recebo o seguinte:

$ loginctl show-session $XDG_SESSION_ID
ControlGroupHierarchy=/user
ResetControllers=cpu
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

De lá, encontrei informações sobre preservação da sessão , que não parece ser aplicável - meu /etc/X11/xinit/xserverrc não é modificado desde a instalação:

$ ls -l /etc/X11/xinit/xserverrc
-rw-r--r-- 1 root root 132 Oct 31  2012 /etc/X11/xinit/xserverrc

O SLiM parece estar funcionando bem:

$ systemctl status slim.service
slim.service - SLiM Simple Login Manager
   Loaded: loaded (/usr/lib/systemd/system/slim.service; enabled)
   Active: active (running) since Sat 2013-08-10 00:00:39 CEST
 Main PID: 258 (slim)
   CGroup: name=systemd:/system/slim.service
           ├─ 258 /usr/bin/slim -nodaemon
           ├─ 292 /usr/bin/X -nolisten tcp vt07 -auth /var/run/slim.auth
           ├─ 416 /usr/bin/gnome-keyring-daemon --daemonize --login
           ├─ 418 awesome
           ├─ 423 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
           ├─ 472 xscreensaver -no-splash
           ├─ 479 firefox
           ├─ 481 java -Xmx192M -jar /usr/share/java/jedit/jedit.jar -reuseview
           ├─ 483 pidgin
           ├─ 485 xterm
           ├─ 500 bash
           ├─ 581 /usr/lib/at-spi2-core/at-spi-bus-launcher
           ├─ 641 xterm
           ├─ 643 bash
           ├─1006 git gui
           ├─1007 wish /usr/lib/git-core/git-gui --
           ├─1367 dbus-launch --autolaunch e943bbb765d74fceb0393a55ceebfd1d --binary-syntax --close-stderr
           ├─1368 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
           ├─1403 ekiga
           ├─1405 /usr/lib/GConf/gconfd-2
           ├─1476 thunar
           ├─1478 /usr/lib/xfce4/xfconf/xfconfd
           └─1589 systemctl status slim.service

O que eu preciso fazer para corrigir a sessão de login e, assim, (presumivelmente) as permissões de áudio?

    
por l0b0 07.08.2013 / 08:31

1 resposta

1

O problema foi o login_cmd as @ jasonwryan insinuou ; Eu deveria ter mantido o valor original ao invés de seguir o [SLiM + GNOME keyring] [7] no GNOME > 2.30 recomendação de configuração:

$ grep login_cmd /etc/slim.conf
# login_cmd           exec /bin/sh - ~/.xinitrc %session
# login_cmd           exec /bin/bash -login ~/.xinitrc %session
login_cmd           exec dbus-launch /bin/bash -login ~/.xinitrc %session >~/.xsession-errors 2>&1

Depois de reverter para login_cmd exec /bin/bash -login ~/.xinitrc %session , agora obtenho mais informações sensatas sobre a sessão:

$ loginctl show-session $XDG_SESSION_ID
Id=c1
Timestamp=Fri 2013-08-09 22:30:28 CEST
TimestampMonotonic=11871667
DefaultControlGroup=systemd:/user/1000.user/c1.session
VTNr=7
Display=:0.0
Remote=no
RemoteUser=root
Service=slim
Leader=260
Audit=0
Type=x11
Class=user
Active=yes
State=active
KillProcesses=no
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
Name=username

Isso realmente corrigiu o problema principal - vlc é capaz de reproduzir vídeos se eu configurá-lo manualmente para usar o primeiro dispositivo de áudio HDA da Intel.

    
por 09.08.2013 / 23:08