11

As you can read, for instance here, logind, which is a part of systemd, can set permissions to some devices for user sessions. There's also a vid showing how this kind of behavior works in practice. In short, if you start, let's say, amarok, and you play some song, you will hear the sound till you switch to another user or TTY where you have only the login prompt. That's because the active session became inactive.

I know that you can simply add a user (or users) to a specific group, in this case "audio", and that will 'fix' this issue, but I'm wondering if there's another solution. What I really want is to set some permissions for the process so it could use the sound card all the time, even when all users have their sessions locked.

Is that possible? I'm asking because I often listen to the music and I don't really need my monitor to be on most of the time, so I just lock the screen. But when I lock the screen, the active session becomes inactive and amarok stops playing. And yes, the screen should be locked, and not just turned off.

EDIT:

I don't think that it matters which distro I'm using because if there's systemd on board, it would be the exact same issue. Anyways, I'm using debian sid, but some packages like systemd, udev (and some dependencies) are from experimental branch, and now it's the 219-9 version.

  • 1
    Possibly running nohup program_x & ; disown could help. Or using screen – JustMe May 7 '15 at 17:24
  • But the process works just fine. When I lock the screen, it can't use the sound card anymore, at least till I unlock the screen. – Mikhail Morfikov May 7 '15 at 17:35
  • Have you tried using loginctl enable-linger for the account? – spuk May 12 '15 at 18:47
  • According to the arch wiki: The systemd user instance is started after the first login of a user and killed after the last session of the user is closed. Sometimes it may be useful to start it right after boot, and keep the systemd user instance running after the last session closes, for instance to have some user process running without any open session. Lingering is used to that effect. That doesn't concern an inactive user session because systemd --user is present all the time. – Mikhail Morfikov May 12 '15 at 20:33
  • I routinely leave my music playing on my Fedora 21 laptop while I sleep after having locked it. So I don't think locking your computer screen should mark a session as inactive just because of systemd. – Bratchley May 17 '15 at 23:58
1

I am not sure, which version/flavor of Linux you are using, but looks like ACL's for sound devices are controlled by ConsoleKit via udev rules. On my Debian host, I see something like below in /lib/udev/rules.d/70-udev-acl.rules

# sound devices
SUBSYSTEM=="sound", TAG+="udev-acl"

I would play with untagging this, so consolekit won't add sound devices into its database and not manage ACL on sound devices

  • I verified on my desktop with commenting above line and after reboot. No more ACL management for sound devices and I can play songs with my screen locked – VenkatC May 13 '15 at 22:18
  • I updated the question. Now, consolekit is obsolete stuff -- you can read more about it here freedesktop.org/wiki/Software/ConsoleKit , and my system doesn't use it. Logind is a replacement for it, and it does basically the same thing. I tried to comment out the line you gave me, and after reboot, my system doesn't see any sound cards. Even if it did and this worked just fine, I don't think that I would use this solution -- it's because It would be the same thing as adding a user to the audio group, at least I see it in this way. – Mikhail Morfikov May 14 '15 at 7:07
  • Thanks, I looked at logind details and yes, it's doing similar stuff. That is looking for udev TAG 'uaccess' to identify devices to manage and it's in /lib/udev/rules.d/70-uaccess.rules. It's all coming down to basic unix permissions, in my opinion you have these options 1) remove sound card tag via udev, so logind doesn't manage audio device and locking screen,switching users - won't change permissions of sound devices. you could set perms as you like 2) you could simply find amarok binary and set it's group to be audio and setgid it, so it's effective group becomes audio – VenkatC May 14 '15 at 15:24
  • I checked the second solution, but unfortunately it doesn't work. I set audio group to the amarok binary, and the permissions are as follows: -rwxr-sr-x, but when I try to start amarok as a regular user, I get this error: QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. unnamed app(24333): KUniqueApplication: Cannot find the D-Bus session server: "Unable to autolaunch when setuid" – Mikhail Morfikov May 14 '15 at 15:53
  • hmm, looks like running setuid programs in GUI seems way complicated and blocked for security reasons for ex: gtk.org/setuid.html. I'll research more and let you know, this is good stuff - learning new things ! – VenkatC May 14 '15 at 16:32
0

Let me say I know little about audio on Linux desktop. Mea Culpa if this won't help.

I would set the group-permissions of the audio device:

chgrp audio <dev-path>
chmod g+rw <dev-path>

to the group that amarok runs in. Use systemd to force amarok to run in that group. First copy the amarok systemd file to /etc/systemd/user/ and modify it:

[Service]
Group=audio

(that's a modification, not the entire file).

But there may be a more "sophisticated" answer due to the multiple layers that are today's Linux-audio system.

  • 1
    As for chgrp audio -- all devices under /dev/snd/ already have the audio group, but this shouldn't matter when you use pulseaudio, and that's the case. When it comes to systemd's service, I tried it, but I got the following error: Failed at step GROUP spawning /usr/bin/amarok: Operation not permitted. amarok.service: main process exited, code=exited, status=216/GROUP, and I don't think that I can change these groups as a regular user. I have other service that requires group change, but it's a normal system daemon, and it works just fine. ` – Mikhail Morfikov May 12 '15 at 13:42
  • The Amarok service isn't started by root? It's possible Amarok needs other group permissions for other puproses. Too bad it isn't that easy. – Otheus May 12 '15 at 13:58
  • It's just a music player. :) – Mikhail Morfikov May 12 '15 at 14:15
0

How about running the player in vnc framebuffer? In Mint 17...

# apt search vfb
p   xvfb                            - Virtual Framebuffer 'fake' X server
p   xvfb:i386                       - Virtual Framebuffer 'fake' X server

You would use VNC to view the desktop as described in https://en.wikipedia.org/wiki/Xvfb

  • I've read the Usage scenarios in the wiki link, and I don't think any of those apply here. The process (amarok) just need some permissions, and I have no idea how to set them, if that's even possible. – Mikhail Morfikov May 12 '15 at 13:49
  • What permissions do you think you need? I highly doubt systemd is changing the permissions on devices just because you switch tty's and if it does i'm going to do my best to avoid it like the plague from now on. I don't know that this will help you either, i didn't test it, but it's the only idea i have that has a chance at working. Also, users have permissions, not processes. – smokes2345 May 12 '15 at 21:10
  • Just read the first link in the question. – Mikhail Morfikov May 13 '15 at 8:51
0

Pulseaudio is started via xdg autostart, which can be found under ~/.config/autostart/ . There's a file called pulseaudio.desktop, and in that file I've changed the default exec line to this one:

Exec=/usr/bin/sg audio -c "pulseaudio -D"

When I log in to the system, the pulseaudio process looks like this:

$ ps -eo user,group,args | grep pulse
morfik   audio    pulseaudio -D
morfik   audio    /usr/lib/pulseaudio/pulse/gconf-helper

And now I'm able to listen to the music all the time. I think this is the solution I was looking for.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.