8

Possible Duplicate:
Open a window on a remote X display (why “Cannot open display”)?

I'm trying to run a cron job that needs access to my X session. I know my X session will always be :0, so part of it is easy:

/30 * * * * DISPLAY=:0 command

but the problem is that gdm3 no longer uses $HOME/.Xauthority; instead it uses /var/run/gdm3/auth-for-anthony-XXXXXX/database where the X's change each login.

Other than symlinking $HOME/.Xauthority to the GDM3 file each login (or editing crontab each login, etc—automatically in .xsession of course), is there some way to get the cron job working?

Community
  • 1
derobert
  • 107,579
  • 20
  • 231
  • 279
  • maybe we can come up with a bash script, but needs to know, is the XXs are numbers or letters or both ? is the old one deleted each logout ? – Hanan Nov 29 '11 at 21:15
  • @HananN. They are letters and numbers, e.g., `JZ7Kpd`. Probably from `mkdtemp`. They likely aren't guessable, and `/var/run/gdm3` is 0711, so you can't list it (except as root) – derobert Nov 29 '11 at 22:42
  • Er. You edited this to basically say "what ways can this problem be solved other than the ways it was solved in a duplicate question"? Is there something wrong with those solutions? – Michael Mrozek Dec 02 '11 at 20:29
  • @MichaelMrozek: Well, they're sort of kluge-ish, but they have to be because they're not making any assumptions (e.g., gdm3). Turns out gdm3 offers a different way to do this, somehow, through its system dbus API. Maybe. Haven't figured it out yet. (Honestly: I'm one of the two close votes. Maybe this question would better be closed as a duplicate, then I could ask and hopefully answer a new, separate question on the gdm3 dbus interface.) – derobert Dec 02 '11 at 21:03
  • @derobert Ok, a new question sounds good. I'll roll this back and close it – Michael Mrozek Dec 02 '11 at 21:08
  • Although the linked question which is given as a possible duplicate does have some solutions that work, it like finding a needle in a haystack. A short answer specific to cron would actually be useful here. – hackerb9 Jun 07 '23 at 02:40

2 Answers2

1

I would assume to try come up with a script which would execute a shell (in login mode, or set the $HOME variable) and access the Xsession. I would doubt this since executing a cronjob would not provide a valid tty for the process and inturn would be difficult to access the Xsession. However, I am curious to know what purpose are you trying to solve by accessing your Xsession? like launch an xterm or browser? If you are trying to do this purely for automation on a headless terminals, then I would suggest you look for other alternatives like automation tools with selenium.

Nikhil Mulley
  • 8,145
  • 32
  • 49
  • 1
    Well, (a) the only things required to access an X session are the DISPLAY and (if enabled) the xauth cookies. A controlling terminal, much less tty, is not needed. So all you need for cron is to set `DISPLAY` and `XAUTHORITY`, the problem is `XAUTHORITY` changes; (b) The purpose is to make a `dcop` call to the Amarok running in my session (yes, I currently plan to run Amarok 1.4 forever.)—in particular, to make it save the current playlist routinely. – derobert Nov 30 '11 at 07:13
0

Ok, how about xauth trying to establish the connection first? The following command contacts the server :0 to create an authorization using the MIT-MAGIC-COOKIE-1 protocol. Clients that connect with this authorization will be untrusted.

    %  xauth generate :0 . trusted

and then add the key entry into the file that was generated

    %  xauth add :0 . <key>

Let me know how it goes.

Nikhil Mulley
  • 8,145
  • 32
  • 49
  • Well, I could add another key on login, but that'd be about the same as just copying the existing key on login. – derobert Nov 30 '11 at 14:27
  • disable the acl with `xhost +` and try. – Nikhil Mulley Nov 30 '11 at 19:16
  • Well, yeah, I could turn off authentication on the X server. Or I could run `su -c 'rm -Rf /'`. Both are generally bad ideas. – derobert Nov 30 '11 at 19:23
  • Ok, out of my mind. I would still go on to think, why not try with ssh to the same host with -Y with ForwardX11Trusted directive set in ssh_config. Good luck. – Nikhil Mulley Dec 01 '11 at 12:35
  • `ssh -Y` forwards the local display over the SSH session, it does this by connecting locally, so it needs `DISPLAY` and `XAUTHORITY`. Honestly, I like the spirit of coming up with random workarounds; but there are already several fairly good ones in the question—the symlinking of ~/.Xauthority being the best, IMO. Gilles's answer on the other question has several more. I'm hoping there is a non-woraround way to do this... – derobert Dec 01 '11 at 14:09
  • Agreed but was getting myself over puzzled on this and desperate to see something as workaround over this seemingly known one. Still.. if you think the command is to be executed locally on which the X is running then perhaps grabbing the environment of gdm processid for Xauthority file and perhaps extract/merge with xauth could help I suppose. – Nikhil Mulley Dec 02 '11 at 04:14
  • 3
    Oooh, I've found a dbus API—will post an answer once I figure out how to use it. org.gnome.DisplayManager /org/gnome/DisplayManager/Display1 org.gnome.DisplayManager.Display.GetX11AuthorityFile if anyone wants to beat me to it. – derobert Dec 02 '11 at 11:15
  • 1
    Wonderful! Looking forward to hear more from ya :-) – Nikhil Mulley Dec 02 '11 at 11:43