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%


* * * * * /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


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


* * * * * /path/to/script arg1 2> /path/to/log
  • 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, 2021 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, 2021 at 17:00
  • If the environment variables you need are in your .profile, your answer may be here
    – doneal24
    Sep 13, 2021 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, 2021 at 17:03
  • 1
    I got it working :D
    – user492155
    Sep 14, 2021 at 11:17

2 Answers 2


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.


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.

  • 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, 2021 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, 2021 at 18:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .