On Sun, 17 Jul 2022, Lee wrote:
On 7/17/22, The Wanderer wrote:
I don't use cron to play sounds, so I can't speak to this directly,
but...
While this may turn out in the end to be pure FUD, when I hear about
things which work properly when run by hand but not when run
automatically on a modern Debian system, my first suspicion is always
that the culprit is the systemd / logind / whatever-it-is "user session"
concept.
I don't know about systemd, but cron sets just a very few environment
vars (interestingly enough, you _do_ get /etc/environment processed).
I'd guess the problem with "works when run interactively but fails
when run from cron" is because most all of the sh setup is skipped for
things started by cron.
I added some debugging commands to the bark.sh script which produces the sounds
to try to see more clearly what is happening.
When bark.sh is called from the command line I hear the barking and command
pactl list short sinks reports:
1 alsa_output.pci-0000_00_1b.0.analog-stereo module-alsa-card.c
s16le 2ch 44100Hz RUNNING
2 alsa_output.pci-0000_23_00.0.analog-stereo module-alsa-card.c
s16le 2ch 44100Hz SUSPENDED
48 alsa_output.pci-0000_03_00.1.hdmi-stereo module-alsa-card.c
s16le 2ch 44100Hz SUSPENDED
but when bark.sh is called by a crontab entry, the same command reports:
Connection failure: Connection refused
When bark.sh is called from cron, the command pacmd list-sinks also reports:
No PulseAudio daemon running, or not running as session daemon.
Following https://wiki.archlinux.org/title/PulseAudio/Examples ,
I am currently looking at installing a file ~/.config/pulse/default.pa
.include /etc/pulse/default.pa
set-default-sink alsa_output.pci-0000_00_1b.0.analog-stereo
but its getting hotter in my place and I work slowly. Roger
