Mageia forum

Mageia 5.0 64 bit.

1) I am trying to run timidity as a daemon on startup. My /etc/rc.d/rc.local consts entirely of the two lines

Code: Select all

#! /bin/sh
/usr/bin/timidity -iAD

This does not work and produces the following error:

Code: Select all

/home/arromdee# systemctl status rc-local.service -l
● rc-local.service - /etc/rc.d/rc.local Compatibility
   Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static)
   Active: active (exited) (Result: exit-code) since Sun 2015-07-12 12:25:46 EDT; 5min ago
  Process: 1416 ExecStart=/etc/rc.d/rc.local start (code=exited, status=0/SUCCESS)
 Main PID: 1444 (code=exited, status=1/FAILURE)
   CGroup: /system.slice/rc-local.service

Jul 12 12:25:46 localhost.localdomain rc.local[1416]: jack_client_new: deprecated
Jul 12 12:25:46 localhost.localdomain rc.local[1416]: Cannot connect to server socket err = No such file or directory
Jul 12 12:25:46 localhost.localdomain rc.local[1416]: Cannot connect to server request channel
Jul 12 12:25:46 localhost.localdomain rc.local[1416]: jack server is not running or cannot be started
Jul 12 12:25:46 localhost.localdomain rc.local[1416]: Couldn't open output device
Jul 12 12:25:46 localhost.localdomain systemd[1]: rc-local.service: main process exited, code=exited, status=1/FAILURE

2) Attempting to debug this, I find that if I run /usr/bin/timidity -iAD as a normal user, it works. If I kill the process and restart it, it still works. However, if I try to run it as root, I get an error:

Code: Select all

 home/arromdee# /usr/bin/timidity -iAD
jack_client_new: deprecated
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
Couldn't open output device

Furthermore, once I get this error, anything that uses audio also fails with this error. It seems as though trying to do this killed something and it stayed killed for all subsequent attempts to use audio.

mcc under "Manage system services by enabling or disabling them" doesn't show either jack or pulseaudio, and I don't know how to restart the server.

You shouldn't start it using rc.local as that way the required services may not be started yet. By default pulseaudio starts with the X11 session.
But even when you don't use pulseaudio but jack, the same applies. Better have a look at https://wiki.archlinux.org/index.php/Timidity#Daemon

Simple question: If you don't start it via rc.local, in a normal desktop session, does

Code: Select all

timidity -iAD

work as expected?

In a normal desktop session, that works as expected either with or without rc.local.

Also, it turns out that not only does the server die when I try to start timidity as root, the server dies when I try *anything that uses audio* as root. If I su and try to play a video, it produces the error and plays without audio; from then on, anything I try to play as a normal user also produces that error and no audio. This behavior is not affected by the rc.local either.

You should run it as normal user either via a systemd user unit as mentioned in above arch wiki link, or via a simple script run by the autostart means of your desktop environment.
So it can either be started via a .desktop file in either /etc/xdg/autostart/ (systemwide for all users) or ~/.config/autostart/

I am using fvwm2 anbd it works in my .fvwm2rc, so that half of the problem is okay. However, I am still in the situation where doing a su (to root or any other user) and using audio kills the server in such a way that not only does the audio not work, I can no longer use audio even as myself. (It turns out that exiting X and restarting will make audio work again.)

That is expected, only one user can have access to the audio device, that is the user with the active session.
There is only a rather hackish workaround for that, add the user that need concurrent access to the audio device to the audio group.

You can see why if you look at the ACLs for the audio devices via

Code: Select all

getfacl /dev/snd/*

For some explanations, see https://wiki.ubuntu.com/Audio/TheAudioGroup
and also the very valuable http://voices.canonical.com/david.henni ... our-audio/


Maybe some workaround can be found if you share WHY you need to run WHAT exactly as root user requiring access to audio device, and some context information on why you do it that way.

That is expected, only one user can have access to the audio device, that is the user with the active session.

That explains why it doesn't work when I try it as another user, but it doesn't explain why running it as another user kills it for all users, even the one who has access.

As you do not provide any detailed information, cannot help you much further.
Please keep in mind that others can only help you remotely as far as you supply sufficient information.

I got the same symptoms in a simpler situation, where no timidity is involved and it's harder to say "don't do that": Note: I am set up so that users log into a command prompt and need startx to start X.

1) login as myself, su
2) startx (Root is using kde and whatever window manager is default.)
3) Observe that sound doesn't work. Same errors as above.
4) Exit from X and from su
5) startx (as myself). My user is using fvwm2 and no kde.
6) Sound still doesn't work and will not work until I reboot.

Note:
-- actually logging in from a login prompt as root (followed by startx) will not cause the same problem
-- However I don't want to log in as root from a login prompt because it triggers https://bugs.freedesktop.org/show_bug.cgi?id=62676
-- Even if pulseaudio is started when I log in, that should mean that audio won't work after I su, but it should *not* mean that audio *permanently* stops working, even after returning from su.

I don't understand why you don't boot automatically to X and then login in whatever DE you feel like.

arromdee wrote:Note:
-- actually logging in from a login prompt as root (followed by startx) will not cause the same problem
-- However I don't want to log in as root from a login prompt because it triggers https://bugs.freedesktop.org/show_bug.cgi?id=62676

Which should be fixed since 2013, if it's the exact same problem.

arromdee wrote:-- Even if pulseaudio is started when I log in, that should mean that audio won't work after I su, but it should *not* mean that audio *permanently* stops working, even after returning from su.

Sorry, not following you. FWIW, do you use "su" or "su -" ?

You need to check your sessions via

Code: Select all

loginctl list-sessions
loginctl show-session cN

Do the latter one for each of them and check if they are active. If they are not, no control handed over to audio device. Simple as that.
To make sure everyone gets and active session and a seat, most people are using login managers that take care of that.
Wonder why for all of the sound works just fine?

In any case, you can still try to add your users to the audio group and see if that helps you in your special case.

Which should be fixed since 2013, if it's the exact same problem.

No, it's not fixed, and that has a comment dated 2015 stating that the problem sometimes still happens. It happens to me on Mageia 5.

Sorry, not following you.

What happens is that I can play sound as a user, then I try playing sound in a su shell, then not only can it not play any sound, when I exit and am back as the user, the user cant play any sound either.

I expect that even if root cannot play sound, attempting to do so should not get my system into a state where even the original user can't play sound any more.

FWIW, do you use "su" or "su -" ?

I used su. I'll try su - when I get a chance.