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