Charade persists after caller termination #9

codex24 opened this Issue Dec 20, 2011 · 4 comments


None yet
2 participants

codex24 commented Dec 20, 2011

It seems that an instance of charade is created each time a new shell is started, and these instances remain running after the shell that started them is terminated. I would expect that either

  • a single instance of charade is created to proxy all requests for the single instance of pageant and that it would persist regardless of the comings and goings of the shells that use it; or
  • that an instance of charade would be created per shell, and then terminate when the calling shell closes.
    As it is, after a while, the system is cluttered with zombie charade instances. I have noticed a similar issue with the native ssh-agent.

wesleyd commented Dec 20, 2011

That sounds sub-optimal!

How do you launch charade? Do you have it installed as ssh-agent and do you launch it via keychain?

My understanding is that keychain takes care of not launching a second ssh-agent/charade process if there's one already running.

I have these two lines in my .bash_profile in my cygwin home directory:
keychain -q -Q
. .keychain/hostname-sh

Do you have something similar, or do you launch ssh-agent/charade directly?

codex24 commented Dec 22, 2011

I am following the directions in the file, that is, in my ~/.bash_profile, I have

keychain -q -Q
. .keychain/`hostname`-sh

Perhaps of relevance is that I am using MinTTY, not PuTTY or the cmd shell "terminal".

  1. Using the SysInternals Process Explorer, I observe the process table as I start and terminate terminal shell sessions. Initially, there are no MinTTY sessions open, and no instances of bash.exe or charade.exe running.
  2. I start a MinTTY session. In the Process Explorer, I see a bash.exe instance appear and then another below it with various other processes as the startup scripts run.
  3. During this shell initialization, charade.exe is spawned beneath a sub-process instance of bash.exe. That sub-process bash instance terminates, and the charade instance changes its parent process to PID 1.
  4. When the interactive shell shows a prompt, the processes it owns look like:
$ ps -fu $USER
kevin_ca    4408       1 con    Dec 20 /usr/bin/XWin
kevin_ca    4852       1   ?  14:51:20 /usr/bin/mintty
kevin_ca    2300    4852   0  14:51:20 /usr/bin/bash
kevin_ca    5884       1   ?  14:51:26 /usr/bin/charade
kevin_ca    5784    2300   0  14:51:53 /usr/bin/ps

and the SSH access envvars look like

$ env | grep -i ssh
  1. Within the interactive shell, I hit ^D to terminate. The shell closes but the charade instance remains running at the first layer of processes in the Process Explorer tree view; i.e., is a child of PID 1.
  2. When the new interactive shell shows a prompt, the processes it owns look like:
$ ps -fu $USER
kevin_ca    4408       1 con    Dec 20 /usr/bin/XWin
kevin_ca    5884       1   ?  14:51:26 /usr/bin/charade
kevin_ca    2228       1   ?  14:53:48 /usr/bin/mintty
kevin_ca    4212    2228   1  14:53:48 /usr/bin/bash
kevin_ca    5108       1   ?  14:53:53 /usr/bin/charade
kevin_ca    4808    4212   1  14:54:10 /usr/bin/ps

and the SSH access envvars look like

$ env | grep -i ssh

So, it looks like charade becomes inaccessible when the intermediate invoking shell terminates, because it attaches to the root process rather than the calling process?


wesleyd commented Dec 23, 2011

Soooo, I've found mintty (nice one - I didn't know about it before!) and charade works sanely with it for me.
That is, it only launches one charade process, no matter how many mintty's I launch. (It doesn't do what yours does.)
Also, ps shows that charade's PPID is 1 for me too.
(Which is actually what we'd want: we don't want charade dying when its bash dies, so it makes sense that its parent should be init (or whatever pid 1 is on these windows boxes.) So I think that's a red herring.)

Tell me this... You see your .keychain directory? What's in it?! (ls -Fla ~/.keychain) I wonder if keychain for some reason isn't communicating properly with itself across launches. Maybe it can't write into ~/.keychain.

Also, does it work? Can you access ssh keys stored in your pageant and ssh into remote hosts without a password prompt?



wesleyd commented Dec 24, 2011

Finally, where is your home directory? Is it, like, c:/cygwin/home/xxx, or somewhere else? And what are its permissions?

Finally, what are the permissions on /tmp?
(Is it rwxrwxrwxt ? I've seen weirdness in the past when /tmp doesn't have the sticky bit. Clutching at straws here...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment