Fedora 36 up-to-date.
$ uname -a Linux e4.eyal.emu.id.au 6.1.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 3 17:22:46 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
I have a script running as root (using sudo) and in it I play a sound paplay /audio/ogg/beginning.ogg and it always worked.
Then a few days ago it stopped and I now get an error. Something changed.
$ sudo paplay /audio/ogg/beginning.ogg Connection failure: Connection refused pa_context_connect() failed: Connection refused
$ sudo ogg123 -q /audio/ogg/beginning.ogg ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
=== Could not load default driver and no driver specified in config file. Exiting.
Is there a simple way to allow playing sounds in this context?
TIA
On 3/19/23 23:22, Eyal Lebedinsky wrote:
Fedora 36 up-to-date.
$ uname -a Linux e4.eyal.emu.id.au 6.1.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 3 17:22:46 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
I have a script running as root (using sudo) and in it I play a sound paplay /audio/ogg/beginning.ogg and it always worked.
Then a few days ago it stopped and I now get an error. Something changed.
$ sudo paplay /audio/ogg/beginning.ogg Connection failure: Connection refused pa_context_connect() failed: Connection refused
$ sudo ogg123 -q /audio/ogg/beginning.ogg ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
=== Could not load default driver and no driver specified in config file. Exiting.
Is there a simple way to allow playing sounds in this context?
You shouldn't. Why are you trying to do that?
Samuel Sieb composed on 2023-03-20 00:31 (UTC-0700):
You shouldn't. Why are you trying to do that?
If the superuser can't do something, how can a mere mortal user be expected to do same? When the superuser determines *everything* works as expected is time enough to create the first regular user.
On 3/20/23 07:22, Eyal Lebedinsky wrote:
Fedora 36 up-to-date.
$ uname -a Linux e4.eyal.emu.id.au 6.1.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 3 17:22:46 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
I have a script running as root (using sudo) and in it I play a sound paplay /audio/ogg/beginning.ogg and it always worked.
Then a few days ago it stopped and I now get an error. Something changed.
$ sudo paplay /audio/ogg/beginning.ogg Connection failure: Connection refused pa_context_connect() failed: Connection refused
Playing sounds from a userid not "logged in" has always been very problematic and took me a lot of experimentations in the past. My current solution is something like: (this is run with the user logged in and "owning" the audio)
pactl load-module module-native-protocol-tcp listen=127.0.0.1 export PULSE_SERVER='tcp:127.0.0.1:4713' pax11publish -e xhost si:localuser:mysecondaryuser
where "mysecondaryuser" should be root in your case.
This is basically - enabling TCP connections to pulseaudio (or pipewire emulation) - making the path available to users able to interact with the X11 session - enabling a user to access the X11 session
No warranty that it will work in your case. No idea how this would be adapted when using Wayland instead of X11.
Regards.
Samuel Sieb:
You shouldn't. Why are you trying to do that?
Felix Miata:
If the superuser can't do something, how can a mere mortal user be expected to do same? When the superuser determines *everything* works as expected is time enough to create the first regular user.
That's *NOT* a good way to do things.
(a) Root shouldn't be used as a general login.
(b) Some things refuse to run, to reinforce point (a).
(c) Root can do things that normal users can't. You may set up an expectation that something works, when it won't actually work for normal users.
(d) People paint themselves into a corner doing things as root, and then have to continue using root, when really they should have started out as a normal user and stayed that way.
(e) You can very easily mess up a system as root. Ordinary users have a much harder time at doing that.
General advice is don't use root (which includes su and sudo) to do anything other than fix faults when it's the only way to things. Root should only be used for things that *require* it. Running system updates and software installations is one example.
Set up an ordinary account for yourself, and always use that. Set up ordinary accounts for other uers. Do everything, and test things, as an ordinary user.
Set up one or more test accounts. So that the day things go badly, you have an unconfigured test account to see how a fresh account will work by default. You have a sacrificial account you do experiments in without messing up your normal account.
On Mon, 20 Mar 2023 17:22:57 +1100 Eyal Lebedinsky fedora@eyal.emu.id.au wrote:
Fedora 36 up-to-date.
$ uname -a Linux e4.eyal.emu.id.au 6.1.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 3 17:22:46 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
I have a script running as root (using sudo) and in it I play a sound paplay /audio/ogg/beginning.ogg and it always worked.
I think this should work, if the user that you are sudoing from is the first user to log into the system. I notice that if I log in (now with pipewire as the sound server), and then login as another user, that new user has no access to sound. This is by design for security reasons. But, I think the logic should be, if you sudo from the user who has sound, the ability to use sound should transfer. You aren't becoming root, you are just temporarily gaining the powers of root as a user, and there doesn't seem to be a security hole if you continue to use sound, as it is still you.
But, I just tried it, playing a video with mplayer. And the video worked, but the sound didn't. My guess is that this used to be a loophole in the sound restriction logic, and someone patched it recently, because they disagree that sudo should be able to play sound in the scenario above.
Is there a simple way to allow playing sounds in this context?
I don't know if pipewire continued the practice, but it used to be possible to start pulseaudio as a sound server that everyone could access, rather than as a service restricted to a single user. When started as a server, every user logged in had access to sound. It was a configuration setting, so you should look in the pipewire documentation to see if it is also possible with pipewire.
Maybe it is the same solution that Roberto recommended.
Tim via users composed on 2023-03-20 20:28 (UTC+1030):
Felix Miata:
If the superuser can't do something, how can a mere mortal user be expected to do same? When the superuser determines *everything* works as expected is time enough to create the first regular user.
...
Set up an ordinary account for yourself, and always use that. Set up ordinary accounts for other uers. Do everything, and test things, as an ordinary user....
That account would be root. I've been using Linux for well over 3 decades. I've had a subscription to at least one Fedora mailing list for as long as Fedora has existed. I have several dozen PCs, each of which, except for one laptop gifted me that I haven't altered, is multi- multiboot. Only a small handful include Windows. Average installations on each is well over a dozen, with over 50 on at least one. I am their only user. Only one filesystem exists on each for mounting to /home, and all installations mount it. Most installations are used for: 1-testing upgrade processes 2-testing alpha/beta installers 3-bug report QA 4-support for users in various forums where particular hardware is typically relevant to identifying problem solutions that typically involve procedures requiring superuser write access
Everyone who reports use of root user doesn't need yet another lecture instead of an answer to a question asked.
On Mon, Mar 20, 2023 at 4:11 AM Felix Miata mrmazda@earthlink.net wrote:
If the superuser can't do something, how can a mere mortal user be expected to do same? When the superuser determines *everything* works as expected is time enough to create the first regular user.
This can actually happen under SELinux (and probably AppArmor). Under SELinux, root is just another account to contain. It is possible to deny root access to something, but provide access to unprivileged users. I don't think I've ever come across the use case, though.
A similar constraint on root is with databases. Databases use their own authentication systems, and root would just be another user if added to the database. You would need to do something special to give root privileges. (Modulo domain sockets that use an auth_plugin for authentication).
Jeff
On Mon, 2023-03-20 at 12:33 -0400, Felix Miata wrote:
Everyone who reports use of root user doesn't need yet another lecture instead of an answer to a question asked.
Everyone who asks to do stupid things, and advises others to do stupid things, needs told otherwise. Your longevity at doing unwise things doesn't negate the issue.
On 20/03/2023 17.22, Eyal Lebedinsky wrote:
Fedora 36 up-to-date.
$ uname -a Linux e4.eyal.emu.id.au 6.1.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 3 17:22:46 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
I have a script running as root (using sudo) and in it I play a sound paplay /audio/ogg/beginning.ogg and it always worked.
Then a few days ago it stopped and I now get an error. Something changed.
$ sudo paplay /audio/ogg/beginning.ogg Connection failure: Connection refused pa_context_connect() failed: Connection refused
$ sudo ogg123 -q /audio/ogg/beginning.ogg ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
=== Could not load default driver and no driver specified in config file. Exiting.
Is there a simple way to allow playing sounds in this context?
TIA
Received a few replies that suggest it is not trivial to do so. Some think it is also unwise.
My current solution is to run the affected script as my non-root user and in it run some parts with sudo (set up to run without a sudo password to avoid script interruption).
BTW: I did try to use su/sudo back to my user, to run from inside the script (which is running as root) but it still fails.
On 3/20/23 21:13, Eyal Lebedinsky wrote:
On 20/03/2023 17.22, Eyal Lebedinsky wrote:
Fedora 36 up-to-date.
$ uname -a Linux e4.eyal.emu.id.au 6.1.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 3 17:22:46 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
I have a script running as root (using sudo) and in it I play a sound paplay /audio/ogg/beginning.ogg and it always worked.
Then a few days ago it stopped and I now get an error. Something changed.
$ sudo paplay /audio/ogg/beginning.ogg Connection failure: Connection refused pa_context_connect() failed: Connection refused
$ sudo ogg123 -q /audio/ogg/beginning.ogg ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
=== Could not load default driver and no driver specified in config file. Exiting.
Is there a simple way to allow playing sounds in this context?
TIA
Received a few replies that suggest it is not trivial to do so. Some think it is also unwise.
My current solution is to run the affected script as my non-root user and in it run some parts with sudo (set up to run without a sudo password to avoid script interruption).
BTW: I did try to use su/sudo back to my user, to run from inside the script (which is running as root) but it still fails.
There used to be an environment variable that pointed to the pulseaudio socket, but that seems to have changed (at least in F37). Check that the XDG_RUNTIME_DIR variable is set. It wasn't when I tested going through root. It should point to /run/user/<pid> which is most likely /run/user/1000 unless you aren't the first user.
On 21/03/2023 15.29, Samuel Sieb wrote:
On 3/20/23 21:13, Eyal Lebedinsky wrote:
On 20/03/2023 17.22, Eyal Lebedinsky wrote:
Fedora 36 up-to-date.
$ uname -a Linux e4.eyal.emu.id.au 6.1.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 3 17:22:46 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
I have a script running as root (using sudo) and in it I play a sound paplay /audio/ogg/beginning.ogg and it always worked.
Then a few days ago it stopped and I now get an error. Something changed.
$ sudo paplay /audio/ogg/beginning.ogg Connection failure: Connection refused pa_context_connect() failed: Connection refused
$ sudo ogg123 -q /audio/ogg/beginning.ogg ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
=== Could not load default driver and no driver specified in config file. Exiting.
Is there a simple way to allow playing sounds in this context?
TIA
Received a few replies that suggest it is not trivial to do so. Some think it is also unwise.
My current solution is to run the affected script as my non-root user and in it run some parts with sudo (set up to run without a sudo password to avoid script interruption).
BTW: I did try to use su/sudo back to my user, to run from inside the script (which is running as root) but it still fails.
There used to be an environment variable that pointed to the pulseaudio socket, but that seems to have changed (at least in F37). Check that the XDG_RUNTIME_DIR variable is set. It wasn't when I tested going through root. It should point to /run/user/<pid> which is most likely /run/user/1000 unless you aren't the first user.
Yet, it is present and set up. I expect that it is lost by sudo... yes it is. I set it up manually and got a similar error: [eyal@e7:~]$ sudo -i [root@e7 ~]# set|grep XDG_RUNTIME_DIR [root@e7 ~]# export XDG_RUNTIME_DIR=/run/user/500 [root@e7 ~]# paplay /audio/ogg/beginning.ogg XDG_RUNTIME_DIR (/run/user/500) is not owned by us (uid 0), but by uid 500! (This could e.g. happen if you try to connect to a non-root PulseAudio as a root user, over the native protocol. Don't do that.) Connection failure: Connection refused pa_context_connect() failed: Connection refused
On 3/20/23 21:37, Eyal Lebedinsky wrote:
On 21/03/2023 15.29, Samuel Sieb wrote:
On 3/20/23 21:13, Eyal Lebedinsky wrote:
On 20/03/2023 17.22, Eyal Lebedinsky wrote:
Fedora 36 up-to-date.
$ uname -a Linux e4.eyal.emu.id.au 6.1.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 3 17:22:46 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
I have a script running as root (using sudo) and in it I play a sound paplay /audio/ogg/beginning.ogg and it always worked.
Then a few days ago it stopped and I now get an error. Something changed.
$ sudo paplay /audio/ogg/beginning.ogg Connection failure: Connection refused pa_context_connect() failed: Connection refused
$ sudo ogg123 -q /audio/ogg/beginning.ogg ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
=== Could not load default driver and no driver specified in config file. Exiting.
Is there a simple way to allow playing sounds in this context?
TIA
Received a few replies that suggest it is not trivial to do so. Some think it is also unwise.
My current solution is to run the affected script as my non-root user and in it run some parts with sudo (set up to run without a sudo password to avoid script interruption).
BTW: I did try to use su/sudo back to my user, to run from inside the script (which is running as root) but it still fails.
There used to be an environment variable that pointed to the pulseaudio socket, but that seems to have changed (at least in F37). Check that the XDG_RUNTIME_DIR variable is set. It wasn't when I tested going through root. It should point to /run/user/<pid> which is most likely /run/user/1000 unless you aren't the first user.
Yet, it is present and set up. I expect that it is lost by sudo... yes it is. I set it up manually and got a similar error:
[eyal@e7:~]$ sudo -i [root@e7 ~]# set|grep XDG_RUNTIME_DIR [root@e7 ~]# export XDG_RUNTIME_DIR=/run/user/500 [root@e7 ~]# paplay /audio/ogg/beginning.ogg XDG_RUNTIME_DIR (/run/user/500) is not owned by us (uid 0), but by uid 500! (This could e.g. happen if you try to connect to a non-root PulseAudio as a root user, over the native protocol. Don't do that.) Connection failure: Connection refused pa_context_connect() failed: Connection refused
I didn't mean to use it as root. The sound system isn't going to let you do that as you found out. I meant you need to set it up after you su back to your user.
On Tue, Mar 21, 2023 at 12:38 AM Eyal Lebedinsky fedora@eyal.emu.id.au wrote:
[...]
There used to be an environment variable that pointed to the pulseaudio socket, but that seems to have changed (at least in F37). Check that the XDG_RUNTIME_DIR variable is set. It wasn't when I tested going through root. It should point to /run/user/<pid> which is most likely /run/user/1000 unless you aren't the first user.
Yet, it is present and set up. I expect that it is lost by sudo... yes it is. I set it up manually and got a similar error:
[eyal@e7:~]$ sudo -i [root@e7 ~]# set|grep XDG_RUNTIME_DIR [root@e7 ~]# export XDG_RUNTIME_DIR=/run/user/500 [root@e7 ~]# paplay /audio/ogg/beginning.ogg XDG_RUNTIME_DIR (/run/user/500) is not owned by us (uid 0), but by uid 500! (This could e.g. happen if you try to connect to a non-root PulseAudio as a root user, over the native protocol. Don't do that.) Connection failure: Connection refused pa_context_connect() failed: Connection refused
Give `sudo -E` a try.
Jeff
On 03/20/2023 10:13 PM, Eyal Lebedinsky wrote:
My current solution is to run the affected script as my non-root user and in it run some parts with sudo (set up to run without a sudo password to avoid script interruption).
Although I don't approve of habitually running as root, I have a suggestion that might help. Years ago I created a little script to play an .mp3 as a wake-up alarm, but there was a little problem. I have my box set to turn itself back on after a power drop if it was on before, but if it happens late at night, I won't be logged in in the morning, and there wouldn't be any sound. However, I learned by experiment that ffmpeg can produce sound even if nobody's logged in. If so, it should be able to do what you're looking for.
Thanks Joe,
On 21/03/2023 16.02, Joe Zeff wrote:
On 03/20/2023 10:13 PM, Eyal Lebedinsky wrote:
My current solution is to run the affected script as my non-root user and in it run some parts with sudo (set up to run without a sudo password to avoid script interruption).
Although I don't approve of habitually running as root, I have a suggestion that might help. Years ago I created a little script to play an .mp3 as a wake-up alarm, but there was a little problem. I have my box set to turn itself back on after a power drop if it was on before, but if it happens late at night, I won't be logged in in the morning, and there wouldn't be any sound. However, I learned by experiment that ffmpeg can produce sound even if nobody's logged in. If so, it should be able to do what you're looking for.
And it works too:
$ sudo ffmpeg -i /audio/ogg/beginning.ogg -f alsa default -loglevel quiet ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: PCH [HDA Intel PCH], device 0: ALC887-VD Analog [ALC887-VD Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 1: ALC887-VD Digital [ALC887-VD Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [Beyond TV] <<<<< Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0
$ sudo ffmpeg -i /audio/ogg/beginning.ogg -f alsa hw:0,3 -loglevel quiet [audio plays]
On 3/20/23 21:13, Eyal Lebedinsky wrote:
On 20/03/2023 17.22, Eyal Lebedinsky wrote:
Fedora 36 up-to-date.
$ uname -a Linux e4.eyal.emu.id.au 6.1.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 3 17:22:46 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
I have a script running as root (using sudo) and in it I play a sound paplay /audio/ogg/beginning.ogg and it always worked.
Then a few days ago it stopped and I now get an error. Something changed.
$ sudo paplay /audio/ogg/beginning.ogg Connection failure: Connection refused pa_context_connect() failed: Connection refused
$ sudo ogg123 -q /audio/ogg/beginning.ogg ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
=== Could not load default driver and no driver specified in config file. Exiting.
Is there a simple way to allow playing sounds in this context?
TIA
Received a few replies that suggest it is not trivial to do so. Some think it is also unwise.
My current solution is to run the affected script as my non-root user and in it run some parts with sudo (set up to run without a sudo password to avoid script interruption).
BTW: I did try to use su/sudo back to my user, to run from inside the script (which is running as root) but it still fails.
Hi Eyal,
Not what you asked BUT WHEN DOES THAT STOP ME!!! <maniacal laughter>
If you are already running as root, use "su" to run your command as a user:
su USER -c "command"
for example: su eyal -c "ogg123 -q /audio/ogg/beginning.ogg"
Because you are already running as root, you won't be prompted for USER's password.
You have to use quotes around the command. Use single quotes if double quotes are used in the command.
-T
On 21/03/2023 17.50, ToddAndMargo via users wrote:
On 3/20/23 21:13, Eyal Lebedinsky wrote:
On 20/03/2023 17.22, Eyal Lebedinsky wrote:
Fedora 36 up-to-date.
$ uname -a Linux e4.eyal.emu.id.au 6.1.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 3 17:22:46 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
I have a script running as root (using sudo) and in it I play a sound paplay /audio/ogg/beginning.ogg and it always worked.
Then a few days ago it stopped and I now get an error. Something changed.
$ sudo paplay /audio/ogg/beginning.ogg Connection failure: Connection refused pa_context_connect() failed: Connection refused
$ sudo ogg123 -q /audio/ogg/beginning.ogg ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
=== Could not load default driver and no driver specified in config file. Exiting.
Is there a simple way to allow playing sounds in this context?
TIA
Received a few replies that suggest it is not trivial to do so. Some think it is also unwise.
My current solution is to run the affected script as my non-root user and in it run some parts with sudo (set up to run without a sudo password to avoid script interruption).
BTW: I did try to use su/sudo back to my user, to run from inside the script (which is running as root) but it still fails.
Hi Eyal,
Not what you asked BUT WHEN DOES THAT STOP ME!!!
<maniacal laughter>
If you are already running as root, use "su" to run your command as a user:
su USER -c "command"
for example: su eyal -c "ogg123 -q /audio/ogg/beginning.ogg"
Because you are already running as root, you won't be prompted for USER's password.
You have to use quotes around the command. Use single quotes if double quotes are used in the command.
-T
Tried it and this does not work for me. Does it work for you?
On 21 Mar 2023, at 08:52, Eyal Lebedinsky fedora@eyal.emu.id.au wrote:
On 21/03/2023 17.50, ToddAndMargo via users wrote:
On 3/20/23 21:13, Eyal Lebedinsky wrote: On 20/03/2023 17.22, Eyal Lebedinsky wrote:
Fedora 36 up-to-date.
$ uname -a Linux e4.eyal.emu.id.au 6.1.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 3 17:22:46 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
I have a script running as root (using sudo) and in it I play a sound paplay /audio/ogg/beginning.ogg and it always worked.
Then a few days ago it stopped and I now get an error. Something changed.
$ sudo paplay /audio/ogg/beginning.ogg Connection failure: Connection refused pa_context_connect() failed: Connection refused
$ sudo ogg123 -q /audio/ogg/beginning.ogg ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
=== Could not load default driver and no driver specified in config file. Exiting.
Is there a simple way to allow playing sounds in this context?
TIA
Received a few replies that suggest it is not trivial to do so. Some think it is also unwise.
My current solution is to run the affected script as my non-root user and in it run some parts with sudo (set up to run without a sudo password to avoid script interruption).
BTW: I did try to use su/sudo back to my user, to run from inside the script (which is running as root) but it still fails.
Hi Eyal, Not what you asked BUT WHEN DOES THAT STOP ME!!!
<maniacal laughter> If you are already running as root, use "su" to run your command as a user: su USER -c "command" for example: su eyal -c "ogg123 -q /audio/ogg/beginning.ogg" Because you are already running as root, you won't be prompted for USER's password. You have to use quotes around the command. Use single quotes if double quotes are used in the command. -T
Tried it and this does not work for me. Does it work for you?
Being the users is sufficient. You have to be in the user session that has the sound system daemons runn8ng.
Or you can use the low level alsa interface.
Barry
-- Eyal Lebedinsky (fedora@eyal.emu.id.au) _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 3/21/23 01:04, Eyal Lebedinsky wrote:
On 21/03/2023 17.50, ToddAndMargo via users wrote:
On 3/20/23 21:13, Eyal Lebedinsky wrote:
On 20/03/2023 17.22, Eyal Lebedinsky wrote:
Fedora 36 up-to-date.
$ uname -a Linux e4.eyal.emu.id.au 6.1.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 3 17:22:46 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
I have a script running as root (using sudo) and in it I play a sound paplay /audio/ogg/beginning.ogg and it always worked.
Then a few days ago it stopped and I now get an error. Something changed.
$ sudo paplay /audio/ogg/beginning.ogg Connection failure: Connection refused pa_context_connect() failed: Connection refused
$ sudo ogg123 -q /audio/ogg/beginning.ogg ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
=== Could not load default driver and no driver specified in config file. Exiting.
Is there a simple way to allow playing sounds in this context?
TIA
Received a few replies that suggest it is not trivial to do so. Some think it is also unwise.
My current solution is to run the affected script as my non-root user and in it run some parts with sudo (set up to run without a sudo password to avoid script interruption).
BTW: I did try to use su/sudo back to my user, to run from inside the script (which is running as root) but it still fails.
Hi Eyal,
Not what you asked BUT WHEN DOES THAT STOP ME!!!
<maniacal laughter>
If you are already running as root, use "su" to run your command as a user:
su USER -c "command"
for example: su eyal -c "ogg123 -q /audio/ogg/beginning.ogg"
Because you are already running as root, you won't be prompted for USER's password.
You have to use quotes around the command. Use single quotes if double quotes are used in the command.
-T
Tried it and this does not work for me. Does it work for you?
Something is funny going on. It does work for me:
$ su Password:
[root@rn6 Misc]# whoami root
[root@rn6 Misc]# su todd -c "ogg123 -q Wagner\ al\ piano\ _\ Stefan\ Mickisch-EpeMHyL-Gio.ogg"
[root@rn6 Misc]#
On 22/03/2023 13.57, ToddAndMargo via users wrote:
On 3/21/23 01:04, Eyal Lebedinsky wrote:
On 21/03/2023 17.50, ToddAndMargo via users wrote:
On 3/20/23 21:13, Eyal Lebedinsky wrote:
On 20/03/2023 17.22, Eyal Lebedinsky wrote:
Fedora 36 up-to-date.
$ uname -a Linux e4.eyal.emu.id.au 6.1.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 3 17:22:46 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
I have a script running as root (using sudo) and in it I play a sound paplay /audio/ogg/beginning.ogg and it always worked.
Then a few days ago it stopped and I now get an error. Something changed.
$ sudo paplay /audio/ogg/beginning.ogg Connection failure: Connection refused pa_context_connect() failed: Connection refused
$ sudo ogg123 -q /audio/ogg/beginning.ogg ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
=== Could not load default driver and no driver specified in config file. Exiting.
Is there a simple way to allow playing sounds in this context?
TIA
Received a few replies that suggest it is not trivial to do so. Some think it is also unwise.
My current solution is to run the affected script as my non-root user and in it run some parts with sudo (set up to run without a sudo password to avoid script interruption).
BTW: I did try to use su/sudo back to my user, to run from inside the script (which is running as root) but it still fails.
Hi Eyal,
Not what you asked BUT WHEN DOES THAT STOP ME!!!
<maniacal laughter>
If you are already running as root, use "su" to run your command as a user:
su USER -c "command"
for example: su eyal -c "ogg123 -q /audio/ogg/beginning.ogg"
Because you are already running as root, you won't be prompted for USER's password.
You have to use quotes around the command. Use single quotes if double quotes are used in the command.
-T
Tried it and this does not work for me. Does it work for you?
Something is funny going on. It does work for me:
$ su Password:
[root@rn6 Misc]# whoami root
[root@rn6 Misc]# su todd -c "ogg123 -q Wagner\ al\ piano\ _\ Stefan\ Mickisch-EpeMHyL-Gio.ogg"
[root@rn6 Misc]#
I can see the difference.
My script suns as root using 'sudo script.sh'
Doing this works: $ su # su eyal -c "ogg123 ... but doing this does not: $ sudo -i # su eyal -c "ogg123 ... nor does this: $ sudo -i # sudo -u eyal "ogg123 ...
So 'su' and 'sudo' set up a different context.
My current solution, as I said before, is to run the script directly and use 'sudo' only where it is needed.
On 3/21/23 21:32, Eyal Lebedinsky wrote:
On 22/03/2023 13.57, ToddAndMargo via users wrote:
On 3/21/23 01:04, Eyal Lebedinsky wrote:
On 21/03/2023 17.50, ToddAndMargo via users wrote:
On 3/20/23 21:13, Eyal Lebedinsky wrote:
On 20/03/2023 17.22, Eyal Lebedinsky wrote:
Fedora 36 up-to-date.
$ uname -a Linux e4.eyal.emu.id.au 6.1.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 3 17:22:46 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
I have a script running as root (using sudo) and in it I play a sound paplay /audio/ogg/beginning.ogg and it always worked.
Then a few days ago it stopped and I now get an error. Something changed.
$ sudo paplay /audio/ogg/beginning.ogg Connection failure: Connection refused pa_context_connect() failed: Connection refused
$ sudo ogg123 -q /audio/ogg/beginning.ogg ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
=== Could not load default driver and no driver specified in config file. Exiting.
Is there a simple way to allow playing sounds in this context?
TIA
Received a few replies that suggest it is not trivial to do so. Some think it is also unwise.
My current solution is to run the affected script as my non-root user and in it run some parts with sudo (set up to run without a sudo password to avoid script interruption).
BTW: I did try to use su/sudo back to my user, to run from inside the script (which is running as root) but it still fails.
Hi Eyal,
Not what you asked BUT WHEN DOES THAT STOP ME!!!
<maniacal laughter>
If you are already running as root, use "su" to run your command as a user:
su USER -c "command"
for example: su eyal -c "ogg123 -q /audio/ogg/beginning.ogg"
Because you are already running as root, you won't be prompted for USER's password.
You have to use quotes around the command. Use single quotes if double quotes are used in the command.
-T
Tried it and this does not work for me. Does it work for you?
Something is funny going on. It does work for me:
$ su Password:
[root@rn6 Misc]# whoami root
[root@rn6 Misc]# su todd -c "ogg123 -q Wagner\ al\ piano\ _\ Stefan\ Mickisch-EpeMHyL-Gio.ogg"
[root@rn6 Misc]#
I can see the difference.
My script suns as root using 'sudo script.sh'
Doing this works: $ su # su eyal -c "ogg123 ... but doing this does not: $ sudo -i # su eyal -c "ogg123 ... nor does this: $ sudo -i # sudo -u eyal "ogg123 ...
So 'su' and 'sudo' set up a different context.
My current solution, as I said before, is to run the script directly and use 'sudo' only where it is needed.
Hi Eyal,
I hate the sudo command. I never use it.
Try running your script with su instead: su root -c "script"
-T
On 3/21/23 23:03, Joe Zeff wrote:
On 03/21/2023 11:14 PM, ToddAndMargo via users wrote:
Try running your script with su instead: su root -c "script"
You only need the quotation marks if what you're sending to su has spaces in it. HTH, HAND.
Or the script has parameters added to the end
On Tue, 2023-03-21 at 22:14 -0700, ToddAndMargo via users wrote:
I hate the sudo command. I never use it.
Try running your script with su instead: su root -c "script"
You might want to explain your reasoning here. These two things are not equivalent, and saying you "hate the sudo command" is not helpful.
poc
On 21 Mar 2023, at 22:57, Barry barry@barrys-emacs.org wrote:
Tried it and this does not work for me. Does it work for you?
Being the users is sufficient. You have to be in the user session that has the sound system daemons runn8ng.
Opp I meant to say: Being the users is NOT always sufficient.
Or you can use the low level alsa interface.
Barry
On 3/22/23 04:21, Patrick O'Callaghan wrote:
On Tue, 2023-03-21 at 22:14 -0700, ToddAndMargo via users wrote:
I hate the sudo command. I never use it.
Try running your script with su instead: su root -c "script"
You might want to explain your reasoning here. These two things are not equivalent, and saying you "hate the sudo command" is not helpful.
poc
Both the "su" and "sudo" command will elevate the user to root. Sudo's quirks have pissed me off for ages. Your mileage may vary.
On Wed, Mar 22, 2023 at 12:33 AM Eyal Lebedinsky fedora@eyal.emu.id.au wrote:
[...] Doing this works: $ su # su eyal -c "ogg123 ... but doing this does not: $ sudo -i # su eyal -c "ogg123 ... nor does this: $ sudo -i # sudo -u eyal "ogg123 ...
So 'su' and 'sudo' set up a different context.
The '-i' option to sudo replaces the environment of the subprocess with a new environment; or in other words you are throwing away all the environment variables and creating a new set. My guess is that the subprocess does not get the environment variables needed for audio due to this. Try the sudo command without '-i'.
On Wed, 2023-03-22 at 04:42 -0700, ToddAndMargo via users wrote:
On 3/22/23 04:21, Patrick O'Callaghan wrote:
On Tue, 2023-03-21 at 22:14 -0700, ToddAndMargo via users wrote:
I hate the sudo command. I never use it.
Try running your script with su instead: su root -c "script"
You might want to explain your reasoning here. These two things are not equivalent, and saying you "hate the sudo command" is not helpful.
poc
Both the "su" and "sudo" command will elevate the user to root. Sudo's quirks have pissed me off for ages. Your mileage may vary.
Not sure what you mean by "quirks". Are you talking about bugs or features? I use "sudo" regularly (e.g. whenever I run 'dnf update') and don't have any issues with it.
poc
On Wed, 2023-03-22 at 07:47 -0400, Go Canes wrote:
On Wed, Mar 22, 2023 at 12:33 AM Eyal Lebedinsky fedora@eyal.emu.id.au wrote:
[...] Doing this works: $ su # su eyal -c "ogg123 ... but doing this does not: $ sudo -i # su eyal -c "ogg123 ... nor does this: $ sudo -i # sudo -u eyal "ogg123 ...
So 'su' and 'sudo' set up a different context.
The '-i' option to sudo replaces the environment of the subprocess with a new environment; or in other words you are throwing away all the environment variables and creating a new set.
In fact 'sudo -i' runs the target user's login scripts (.login, .profile etc.). The environment can be configured by the user's entry in /etc/sudoers. See sudoers(5).
poc
On Wed, Mar 22, 2023 at 8:42 AM ToddAndMargo via users < users@lists.fedoraproject.org> wrote:
On 3/22/23 04:21, Patrick O'Callaghan wrote:
On Tue, 2023-03-21 at 22:14 -0700, ToddAndMargo via users wrote:
I hate the sudo command. I never use it.
Try running your script with su instead: su root -c "script"
You might want to explain your reasoning here. These two things are not equivalent, and saying you "hate the sudo command" is not helpful.
poc
Both the "su" and "sudo" command will elevate the user to root. Sudo's quirks have pissed me off for ages. Your mileage may vary.
There is also doas. Sudo has grown to support use cases beyond the needs of many/most users.
On 3/22/23 05:19, George N. White III wrote:
On Wed, Mar 22, 2023 at 8:42 AM ToddAndMargo via users <users@lists.fedoraproject.org mailto:users@lists.fedoraproject.org> wrote:
On 3/22/23 04:21, Patrick O'Callaghan wrote: > On Tue, 2023-03-21 at 22:14 -0700, ToddAndMargo via users wrote: >> I hate the sudo command. I never use it. >> >> Try running your script with su instead: >> su root -c "script" > > You might want to explain your reasoning here. These two things are not > equivalent, and saying you "hate the sudo command" is not helpful. > > poc Both the "su" and "sudo" command will elevate the user to root. Sudo's quirks have pissed me off for ages. Your mileage may vary.There is also doas. Sudo has grown to support use cases beyond the needs of many/most users. -- George N. White III
$ dnf whatprovides doas Last metadata expiration check: 13:42:49 ago on Tue 21 Mar 2023 04:18:18 PM PDT. opendoas-6.8.2-2.fc37.x86_64 : Portable fork of the OpenBSDs doas command Repo : fedora Matched from: Provide : doas = 6.8.2-2.fc37
Even if OP aka root can be convinced of the evil(1) of his ways, he will likely want to know why something that used to work suddenly quit.
My guess is that the answer lies with whatever was "updated" recently, but I have no special sound expertise.
(1) clearly evil, not just error
Hi
On Mon, 20 Mar 2023 23:02:20 -0600 Joe Zeff wrote:
Years ago I created a little script to play an .mp3 as a wake-up alarm, but there was a little problem. I have my box set to turn itself back on after a power drop if it was on before, but if it happens late at night, I won't be logged in in the morning, and there wouldn't be any sound.
systemd provides a way to achieve that with:
loginctl enable-linger LOGNAME
From man loginctl:
enable-linger [USER...], disable-linger [USER...] Enable/disable user lingering for one or more users. If enabled for a specific user, a user manager is spawned for the user at boot and kept around after logouts. This allows users who are not logged in to run long-running services. Takes one or more user names or numeric UIDs as argument. If no argument is specified, enables/disables lingering for the user of the session of the caller.
As in addition PipeWire is launched with a user systemd socket/service that should work.
A systemd user manager creates the XDG_RUNTIME_DIR (/run/user/UID) and has this variable in its environment:
systemctl --user show-environment <snip> XDG_RUNTIME_DIR=/run/user/1000
-
Barry -
Barry Scott
-
Eyal Lebedinsky -
Felix Miata -
Francis.Montagnac＠inria.fr -
George N. White III -
Go Canes -
Jeffrey Walton -
Joe Zeff -
Michael Hennebry -
Patrick O'Callaghan -
Roberto Ragusa -
Samuel Sieb -
stan -
Tim -
ToddAndMargo