I need to run shell script contains Xdotool codes in /home/z/Desktop/tempo/run.sh. I've tried many ways of DISPLAY=:0 but always not works.

I've tried each of below codes, and not works:

* * * * * export DISPLAY=:0 cd /home/z/Desktop/tempo; ./run.sh
* * * * * export DISPLAY=:0; cd /home/z/Desktop/tempo; ./run.sh
* * * * * export DISPLAY=:0 && cd /home/z/Desktop/tempo; ./run.sh
* * * * * DISPLAY=:0 cd /home/z/Desktop/tempo; ./run.sh
* * * * * DISPLAY=:0; cd /home/z/Desktop/tempo; ./run.sh
* * * * * DISPLAY=:0 && cd /home/z/Desktop/tempo; ./run.sh

Running directly also not works:

* * * * * export DISPLAY=:0 xdotool mousemove 20 20
* * * * * export DISPLAY=:0; xdotool mousemove 20 20
* * * * * export DISPLAY=:0 && xdotool mousemove 20 20
* * * * * DISPLAY=:0 xdotool mousemove 20 20
* * * * * DISPLAY=:0; xdotool mousemove 20 20
* * * * * DISPLAY=:0 && xdotool mousemove 20 20

I always don't see my mouse moving on each line of codes above.

I've also tested Xdotool codes to make invalid website URI request and see the logs. Sadly the logs still blank.

  • You need to export XAUTHORITY variable before calling X utilite from cron. – Eddy_Em Mar 15 '13 at 13:08
  • 1
    xhost + might work. Not recommended unless you are alone behind a firewall, though; it disables all X11 host access checks. xhost - to revert to the default behavior. – user Mar 15 '13 at 13:34
  • 2
    In this case it's probably better to look for a way of scheduling tasks from inside your desktop environment or window manager. – user Mar 15 '13 at 13:35
  • if you are curious about what's going on, redirect the stdout and stderr of the scripts to a file and check what messages appear there. – peterph Mar 15 '13 at 15:12
  • Related: Cron xdotool doesn't run. – kenorb Feb 5 '19 at 11:34
 * * * * * DISPLAY=:0 xdotool mousemove 20 20

At least should work as long as it's in the crontab of the same user as the one having the X session on the corresponding display.

If another user is to do the mousemove, you need to grant him access to your display. This can be done by giving him the MIT Magick Cookie for your display and let him install it in his own X auth store (using xauth), or it can be done with:

xhost +si:localuser:the-user

Or it can be done by granting him access to your own X auth store, for instance, by doing:

setfacl -m u:the-user:r ~/.Xauthority

And change the crontab line to:

* * * * * DISPLAY=:0 XAUTHORITY=~me/.Xauthority xdotool...

If that other user is root you don't need the setfacl step, but I would not run xdotool as root, no reason for that. You can run it as your own user.


cron jobs don't even have a tty, let alone an X display.

If you want to test a GUI replaying inputs (or generating synthetic load), look for that. Don't try to (ab)use cron.

  • Do you mean its not possible to schedule Xdotool using cron? – apasajja Mar 15 '13 at 13:42
  • +1 for the abuse part :) But please do consider, that spawning an XTerm in a running X session from linux console is very similar, and not necessarily an abuse. – peterph Mar 15 '13 at 15:09
  • @peterph, spawing an Xterm in a running X session is fundamentally different: There is a running X session, for starters. A cron job might run in the middle of the night, with no users connected (no active X sessions around), or even when the machine is in what is traditionally runlevel 2 (no X, no network). – vonbrand Mar 15 '13 at 15:15
  • @vonbrand yes and no. OP obviously has an X session running. Of course using xdotool to e.g. prevent screensaver from starting doesn't sound as a good idea (that was my +1). But I've seen even that in a corporate environment on Windows ...and sadly enough it was a valid workaround). – peterph Mar 15 '13 at 15:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.