MSGID:  9f478b0c
REPLY: <10dei3u$27uve$7@dont-email.me> 9f9c44b5
PID: PyGate 1.5
TID: PyGate/Linux 1.5
CHRS: CP1252 2
TZUTC: 0100
REPLYADDR bulleid@ku.gro.lioff
REPLYTO 3:633/10 UUCP
In message <10dei3u$27uve$7@dont-email.me>, Lawrence 
=?iso-8859-13?q?D=FFOliveiro?=  writes
>On Thu, 23 Oct 2025 19:09:02 +0100, Adrian wrote:
>
>> If I do a cut and paste of the aplay command, it works fine. So the
>> problem looks as though it is some thing to do with the python call.
>
>I would try to confirm this by running the Python script (or at least
>a copy of the part that does the aplay command) from a terminal
>session. In other words, try to minimize all the differences between
>the situation where you can successfully invoke the command, and the
>one where you can?t.
>

Thanks for the detailed reply.

I've just tried that, and running the Python interactively works (I get 
sound). So far, so good.

In the normal way of things, the Python code is started by cron using 
@reboot.  Being aware that the environment that cron gets can be 
different to that of an interactive session, I've just killed off the 
background Python code, and restarted it using nohup (which I think 
should give the same environment as the command line).  That still fails 
(code runs, no sound), but now the error message doesn't appear, instead 
in the error file, I get the message :

nohup: ignoring input and appending output to 'nohup.out'

which it doesn't, that file remains empty.

So it looks as though the problem is with the Python code running in the 
background, rather than the Python code itself.  I'm wondering if one of 
the updates that has run since the previous reboot (~8 weeks ago) has 
come into play because of yesterday's reboot.

I forgot to mention that the path to the sound file is absolute, rather 
than $HOME/...

When I run Python from the command line, it tells me that I'm running 
Python 3.11.2


>> Both command line and python are running under the same user.
>
>I suspect there is some issue with setup of environment variables
>(e.g. $HOME) when running the script in the background versus
>interactively.

I would agree, but see above.  And why did it work pre-reboot ?

>
>> What I'm seeing logged by the python code is the following error :
>>
>> ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave
>> aplay: main:831 audio open error: Unknown error 524
>>
>> I've tried rebooting again, and an Internet search doesn't come up
>> with anything for my particular problem (they all seem to be
>> "nothing working").
>
>I did a search for ?alsa Unknown error 524? and found this
>open-audio-device-unknown-error-524-what-is-going>
>where the error was fixed by putting something into the systemwide
>ALSA config.
>
>This would be consistent with my suspicion that the per-user setup
>for your background versus interactive cases is not exactly the same.

Thanks.  I tried adding those entries, but it makes no difference.

And to repeat, the background and foreground sessions are run by the 
same user, so I think the problem is "how it is being run" rather than 
"who is running it".

Adrian
-- 
To Reply :
replace "bulleid" with "adrian" - all mail to bulleid is rejected
Sorry for the rigmarole, If I want spam, I'll go to the shops
Every time someone says "I don't believe in trolls", another one dies.

--- PyGate Linux v1.5
 * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
SEEN-BY: 105/81 106/201 128/187 129/14 305 153/7715 154/110 218/700
SEEN-BY: 226/30 227/114 229/110 111 200 206 275 300 317 400 426 428
SEEN-BY: 229/470 616 664 700 705 266/512 291/111 292/854 320/219 322/757
SEEN-BY: 342/200 396/45 460/58 633/10 280 414 418 420 422 509 2744
SEEN-BY: 712/848 770/1 902/26 2320/105 5020/400 5075/35
PATH: 633/10 280 229/426