2

I have a script that executes perfectly fine manually, though two commands in particular are completely ignored by Cron (this is just a snippet):

sinkint=$(pacmd list-sinks | sed -n '/index\W [1-9]/p' | sed 's/.*://g;s/\W//g')

pacmd set-default sink $sinkint
pacmd set-sink-volume $sinkint 20%

Crontab

* * * * * /path/to/script arg1 >> /path/to/log

Error messages

No PulseAudio daemon running, or not running as session daemon.
No PulseAudio daemon running, or not running as session daemon.
You have to specify a sink name/index and a volume

Edit:

tried variables in script

export PULSE_SERVER=unix:/tmp/pulse-socket
export PULSE_COOKIE=/tmp/pa_cookie

socket in my /etc/pulse/default.pa

load-module module-native-protocol-unix socket=/tmp/pulse-socket

socket and cookie in my /etc/pulse/client.conf

default-server = unix:/tmp/pulse-socket
cookie-file = /tmp/pa_cookie

crontab -e

PULSE_SERVER=unix:/tmp/pulse-socket
PULSE_COOKIE=/tmp/pa_cookie

    

    • 

      • 

        • 

          • 

          • /path/to/script arg1 2> /path/to/log
            • 

          

          • 

        

        • 

      

      • 

    

    •
user492155
  • 51
  • 2
    You should have the output with the error on your user mail. Just be aware that usually Cron issues come from env variables that just aren't as you expect when the script runs. You might be missing something with the PATH variable. – Zip Sep 13 '21 at 16:39
  • 3
    If those error messages come from the commands in question, then they're not "completely ignored" by cron, but would seem to launched as desired, just with some other problem. It might be that pacmd needs some environment variables or such to find the server, at least the Arch Linux wiki mentions PULSE_SERVER and PULSE_COOKIE. You may want to check that whatever it needs to find the daemon is available under cron, too. – ilkkachu Sep 13 '21 at 17:00
  • If the environment variables you need are in your .profile, your answer may be here – doneal24 Sep 13 '21 at 17:02
  • Please [edit] your question and add the output of env | grep -i pulse from a shell where the script works. You're probably missing an environment variable that is being set by pulseaudio in your session but not in the session run by cron. – terdon Sep 13 '21 at 17:03
  • Relating https://unix.stackexchange.com/a/378999/117549 – Jeff Schaller Sep 13 '21 at 17:07
  • @terdon that doesn't return anything – user492155 Sep 13 '21 at 17:10
  • @ilkkachu that seems promising, do you suggest I add those environment variables straight into my crontab? – user492155 Sep 13 '21 at 17:16
  • @user492155 that can't be. You have both PULSE_SERVER and PULSE_COOKIE there. Did you maybe run grep without the -i? Anyway, I would have suggested setting those two, and you did and it didn't help, so... – terdon Sep 13 '21 at 22:20
  • yeah, I checked all my environment variables and there's no pulse anywhere... lmao – user492155 Sep 13 '21 at 22:22
  • either I got pulse audio set up wrong, or I have no idea what I'm doing with these variables haha – user492155 Sep 13 '21 at 22:55
  • @user492155, I can't say, I don't pretty much anything about the internals of pulseaudio, or how it's commonly started. If it sets those variables somewhere/somehow when starting the server, they'd change at least on reboot etc. You'd need to have them stored in some file and have the crontab entry read that file to get them. – ilkkachu Sep 14 '21 at 09:04
  • 1
    I got it working :D – user492155 Sep 14 '21 at 11:17

2 Answers2

3

adding XDG_RUNTIME_DIR=/run/user/1000 to crontab worked!

annoyingly... because it was literally the only enviroment variable that I needed. Oh well, if anybody needs the answer in the future - here it is I guess.

user492155
  • 51
-3

Jobs run through cron, or systemd startup scripts aren't run in the same runtime environment that you have on your desktop. systemd startup scripts are run as root. None of your PATH changes, or other environment variable settings from ~/.bashrc are automatically propagated to your cron job. For example, there's no $DISPLAY, so GUI programs need special treatment (read man xhost).

One can set environment variables for all one's cron jobs in the crontab file Read man 5 crontab.

Look at the results of echo "=== id ===";id;echo "=== set ===";set;echo "=== env ===";env | sort;echo "=== alias ===";alias in each of your environments.

Since the command part of the crontab line is, by default, interpreted by /bin/sh, which has a simpler syntax than /bin/bash, I recommend having command be a call to a bash script (executable, mounted, starts with #!/bin/bash) which sets up the environment, then calls the desired program.

waltinator
  • 4,865
  • 1
    You've posted this answer to at least two questions, without changing it at all to reflect the specific question. Taking into account that the issue was solved by the OP through setting XDG_RUNTIME_DIR, your answer reads more like a comment offering generic debugging help than an actual answer. – Kusalananda Sep 23 '21 at 13:53
  • Since "My program doesn't work via crontab" questions appear far too frequently, I've tried to write a generic answer. It usually guides the user to the "right" answer. Can you suggest improvements? – waltinator Sep 23 '21 at 18:19