Encountered a strange problem.
After quite a while I did a system update, with all that systemd, new kernel and stuff, like more than half a year of updates.
Then when I tried to run cmus and play some music, it would hang and only kill -9 would help.
So I removed the .cmus directory from user's home dir and tried to run cmus.
The outcome is that the cursor goes one line down and just blinks there. Nothing happens, no errors are being diplayed, nothing in logs - it just sits there and blinks. Ctrl+C works.
However, if I run it through 'sudo cmus', it works and even plays some music... So I presume it must be something to do with permission rights... The user is in audio group.
The architecture is x86_64.
I searched arch forums and internet but couldn't find anything useful.
Does anybody have any idea what and where to change for cmus to work? If there is any more information required just tell me. Thanks in advance.
The user is in audio group.
As mentioned in the wiki (and probably some topics here) that should not be necessary and apparently it can even cause problems (though I haven't seen an explanation of how or what kind of problems). So a simple thing to try is removing your user from the audio group (and maybe other groups like video/storage).
I had audio problems after booting with a mixed systemd/sysvinit setup, but everything has been fine since I ditched sysvinit completely, so I haven't explored and uncovered any details that might help you, unfortunately.
Have you tried other players? (think aplay or speaker-test) And do you have any other permission problems? E.g., can you run `systemctl (suspend|poweroff|...)` without sudo, or mount removable devices with udisks? Otherwise you should check your session with loginctl (but then you should have come across that when searching).
Last edited by Raynman (2012-11-11 20:29:13)
This, and Tom's follow-up mail. Anything device that matches a rule in /usr/lib/udev/rules.d/70-uaccess.rules is tagged with 'uaccess', thereby making logind manage its permissions via ACL; sound devices are the most obvious.
As Raynman mentioned, see if it's only cmus or if other programs exhibit similar symptoms, and ensure you aren't breaking the logind session (if using startx/xinit, ensure x is starting on the tty you logged into as is done by the stock xserverrc in xorg-xinit; display managers with systemd services should handle the session fine).
Last edited by ZekeSulastin (2012-11-11 21:46:35)
Thanks for the information.
Now it is starting to make sense.
Yes I do have problems with other software, like audacious segfaults each time I run it as a user.
I followed the advice from the systemd wiki and removed myself from the audio group, but then I encountered another problem.
I am using two soundcards - one integrated (intel) and one external usb (SB). When I was not in the audio group I had no sound on the external card. Each and every program was playing, card was detected, channels unmuted, levels set up, everything seemd fine and there still was NO sound. It was _infuriating_ as I was doing everything EXACTLY as wiki and numerous web articles advised, and still was missing the sound.
I lost two days of meddling with my system to finally try to get back to audio group and suddenly the sound was back. You can imagine how "happy" I was with ARCH devs. I lost my will to play with my system when I left gentoo and here I was back again.
And now you're telling me I have to remove myself again. Well whoopsie-fuc..n-do.
But thanks to ZekeSulastin link now at least I know where to look for solution. Seems like I have to add my usb hardware entr(y|ies) to that 70-uacces.rules file.
I don't really know for sure but I am quite confident that I didn't encounter any information whatsoever in the documentation about adding your usb sound card (or any hotplugged hardware) to that config file.
And real thanks to you guys, I'll try to fix it and let you know how it went.
That was a very sad story... I cried a little.
You sir are a very decent and compassionate _human_ being. KUDOS to you.