Monument ([info]marnanel) wrote,
@ 2007-09-16 09:09:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Entry tags:code

[nargery] reattach
Nargery: Rudd-O's idea in Behdad's post about setting the cwd of a running process made me think that the same principle could usefully be used elsewhere. In particular, I have screen sessions which run for months; the connection to the server doesn't stay up that long, and so by the end of it DISPLAY is usually out of date, which means I'd either have to keep it updated manually in each of (perhaps a dozen) screens, or run X programs outside screen, which is icky. A similar thing happens with ssh-agent, when I'm using screen on localhost rather than remotely: the original agent is often weeks dead by the time I reattach, because I've restarted X in the meantime.

So I made this script, offered in case it's useful without warranty. Add or remove variables from @FIXABLE_VARIABLES as you have need. Feedback welcome.


(Post a new comment)


[info]9000
2007-09-16 06:21 pm UTC (link)
A nice hack!

(Reply to this)


(Anonymous)
2007-09-16 06:51 pm UTC (link)
You do realize that screen has the :setenv command, right?
screen -rx -X eval 'setenv DISPLAY :0.0' does what it looks like it should do. No ptrace/gdb trickery needed.

(Reply to this) (Thread)

[info]marnanel
2007-09-16 06:59 pm UTC (link)
You misunderstand. Your solution will set the environment of the running screen session, which will only be passed to new child processes. What use is that? I would have to kill all the existing child processes of my screen session and create new ones. I might as well just have created a new screen session.

(Reply to this) (Parent)(Thread)

(Anonymous)
2007-09-16 08:01 pm UTC (link)
Ah, I didn't notice the finding-child-processes code.

Personally, I end up copy'n'paste-ing export DISPLAY=:0.0 into each window I have open in screen, if it's running sh. Otherwise, if it's running something like irssi, I have no use for DISPLAY anyways.

I should have looked at your script a little closer. That's kinda evil and interesting.

(Reply to this) (Parent)
Really nice hack, appreciate the mention as well
(Anonymous)
2007-09-16 10:19 pm UTC (link)
It's Rudd-O here. I just picked this story up on my blog:

(the post in question (http://rudd-o.com/archives/2007/09/16/you-gotta-love-free-software-linux-and-the-internet/))

(Reply to this)


[info]simont
2007-09-17 12:38 pm UTC (link)
I deal with ssh-agent using a rather lower-tech solution based on the fact that symlinks to Unix-domain sockets work fine. In my .bash_profile I put the following snippet:
auth_pivot=$HOME/.ssh/agent-socket
case "$SSH_AUTH_SOCK" in
  "") ;;
  "$auth_pivot") ;;
  *) rm -f $auth_pivot
     ln -s $SSH_AUTH_SOCK $auth_pivot
     export SSH_AUTH_SOCK=$auth_pivot ;;
esac
unset auth_pivot
so that I always end up with SSH_AUTH_SOCK pointing at the same pathname, which is a symlink to wherever the real agent socket currently happens to be. Hence, when I start up screen, it picks up that standard value of the variable and passes it to all its child processes; I can then detach and log out, and when I log back in the symlink gets updated and all the child processes of screen once again have working agent details.

Wouldn't help with DISPLAY, admittedly. Fortunately this isn't a problem for me because I don't generally run X programs from the machine I run screen on; but if it was, I think I'd be more inclined to deal with it in a similar way using an explicit redirector than by doing scary stuff to the insides of processes. In this case, I suppose the redirector would have to be something like a persistent process which grabbed an X display port and held on to it for the entire lifetime of my screen session, and to which I could then periodically send some sort of message telling it what other X display port it should currently be forwarding new connections to. It would probably also maintain its own X authority file to go with it. Possibly it might also take care of forcibly breaking all the old connections on detach, but then again possibly not.

(Reply to this) (Thread)

[info]simont
2007-09-17 02:34 pm UTC (link)
Or, hang on, a better idea for the X display might be to LD_PRELOAD a library which overrode XOpenDisplay() and caused it to redirect via some external entity such as a symlink or config file. Slightly more intrusive to the client processes, but not by nearly as much as the gdb solution, and avoids the post-initialisation overhead of my previous solution.

(Reply to this) (Parent)(Thread)

[info]marnanel
2007-09-17 02:38 pm UTC (link)
There's also the possibility, which I briefly considered, of specifically hacking bash so that it responds to a certain signal by reading new values for a certain set of environment variables from somewhere.)

(Reply to this) (Parent)(Thread)

[info]simont
2007-09-17 02:50 pm UTC (link)
Hmm. It's entirely possible that bash can already do that using the "trap" command, and all you'd have to do would be to write an appropriate fragment in your .bashrc.

(Reply to this) (Parent)(Thread)

(Anonymous)
2007-09-17 07:17 pm UTC (link)
$ trap '. ~/.bash_environ 2>/dev/null' SIGHUP
$ echo $DISPLAY

$ echo DISPLAY=:0.0 >~/.bash_environ
$ kill -HUP $$
$ echo $DISPLAY
:0.0

(Reply to this) (Parent)(Thread)

[info]marnanel
2007-09-17 07:24 pm UTC (link)
a winner is you!

(Reply to this) (Parent)

Create an Account
Forgot your login?
Login w/ OpenID
English • Español • Deutsch • Русский…