0

I've just made a perfectly working Bash script that runs xprop(by a regular user and root):

#!/bin/bash
# time tracking BASH script

# current time and date
current_date=$(date --rfc-3339='seconds')

# active window id
window_id=$(xprop -root 32x '\t$0' _NET_ACTIVE_WINDOW | cut --fields 2)

# active window class
wm_class=$(xprop '\t$0\n' -id $window_id WM_CLASS | cut --fields 2)

# active window name
wm_name=$(xprop '\t$0\n' -id $window_id _NET_WM_NAME | cut --fields 2)

echo '"'$current_date'", '$wm_class', '$wm_name

with the following output (run as a regular user and root):

nelson@triplecero:~$ bash-scripts/time-tracking.sh
"2019-10-16 23:28:41-04:00", "konsole", "nelson@triplecero: ~ — Konsole"

the script is called from a regular user crontab but then it doesn't work as expected, writing an error messages in the log: "xprop: unable to open display ''", which is the typical error message displayed when xprop (and any GUI program) is not run by the current session user, which is not case because I can run xprop (and any other guy program) as the root user.

The crontab (for the regular user) is like this:

# m h  dom mon dow   command
  * *    *   *   *   /home/nelson/bash-scripts/time-tracking.sh >> /home/nelson/log/time-tracking.log 2>&1
  * *    *   *   *   window_id=$(xprop -root 32x '\t$0' _NET_ACTIVE_WINDOW | cut --fields 2) 2>&1; echo $window_id >> /home/nelson/log/test.log 2>&1
 

the first line is executed with the following error messages in time-tracking.log:

xprop:  unable to open display ''
xprop:  unable to open display ''
xprop:  unable to open display ''
"2019-10-16 23:21:01-04:00", ,

while the second one just create blank lines in test.log

What am I doing wrong in cron to get those error messages instead of the right output?

2

You're missing the $DISPLAY environment variable. It is set by the first process that initializes your GUI session and then inherited by all its child processes. For a local X11 session, the value is normally :0.

The $DISPLAY variable tells X11 applications how to contact the X server; the value :0 tells them to use a local Unix socket at /tmp/.X11-unix/X0. After the initial connection, higher performance access methods like Direct Rendering Infrastructure (DRI) can be enabled.

Cron jobs don't get the $DISPLAY variable automatically, because they're supposed to run independent of the GUI session: what if the owner of the job is not logged in at the moment? If a cron job could just gain access to anyone's X11 session, it would enable the users to spy on each other, and that is not acceptable at all.

Depending on the distribution you're using, you may also need to set the $XAUTHORITY environment variable. Without it, all the X11 tools and applications will assume that the X11 session cookie is located at $HOME/.Xauthority, but as an example, Debian 10 does private $TMP directories for every user, so $TMP will be set to /tmp/user/<user's UID number> and $XAUTHORITY will be set to $TMP/xauth-<user's UID number>-_0 for DISPLAY :0.

Without access to the correct X11 session cookie, the X11 server won't respond to requests, not even for root. Running GUI programs after logging in as a regular user and then using su or sudo to become root is possible if and only if the $DISPLAY (and $XAUTHORITY, if necessary) are passed on to the su/sudo session - which is often set up to happen by default.

  • I put two lines at the very beginning of the bash script: DISPLAY=':0'and XAUTHORITY='/home/nelson/.Xauthority and echoed both into the log file, showing its respective values, but still with no X11 properties: "2019-10-17 13:32:01-04:00", , , :0, /home/nelson/.Xauthority – abiyi Oct 17 at 17:35
  • the $XAUTHORITY doesn't work even in console. I try to execute GUI apps in a root session using two approaches: pam setup and $XAUTHORITY, the first one worked perfectly, the second one didn't. wiki.archlinux.org/index.php/Running_GUI_applications_as_root – abiyi Oct 17 at 17:41
  • I don't see any /tmp/nelson/1002 folder nor /tmp/xauth-1002_0... and I'm using Debian 10.1. – abiyi Oct 17 at 17:46
  • Nevermind: I just was missing to use the word export before every environment variable, the Bash script now works as expected. – abiyi Oct 18 at 0:54

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.