From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 Galeon/1.3.17 Description of problem: When users log out of FC3 the ssh-agent started with their session continues to hang about indefinetly. Version-Release number of selected component (if applicable): openssh-clients-3.9p1-7 How reproducible: Always Steps to Reproduce: 1. Log in to an X session on FC3. 2. Log out. 3. Log in to a virtual console as root and do a ps ax Actual Results: Assuming that no users are logged into a session no /usr/bin/ssh-agent processes to appear. Expected Results: ssh-agent process is still going but is suspended. Additional info: We use FC3 in a multi-user environment so having stacks of processes mounting up like this is eventually problematic. I haven't had time to narrow down the cause but assuming it doesn't always happen, maybe it has something to do with the user's home directory being NFS mounted...
I got the same problems. I noticed that after logout SSH_AGENT_PID is unset, but it's set when you're logged.
Further to what was reported in bug 139372 I tested this in GNOME, KDE and XFCE. All three desktops show this problem.
ssh-agent is started from /etc/X11/xinit/xinitrc-common (which is owned by xinitrc-4.0.14-1 ). A quick comparison to FC1 shows the way ssh-agent is used has changed. FC1: exec ssh-agent /etc/X11/xinit/Xclients FC3: [ -x /usr/bin/ssh-agent -a -z "$SSH_AGENT_PID" ] && eval $(/usr/bin/ssh-agent -s) Because ssh-agent is no longer launched with a command, it will run until it's told to die (as opposed to dying when its command command dies). Unfortunately I don't know if anything tells it to die now... (presumably the display manager will have to do this). I'm not sure what happens in the case where X crashes either...
I'm not sure if this is correct protocol but I'm going to cc mharris on this bug since the changelog says he made the change so he will know whether this is a real bug or not. (if it's not correct protocol - sorry! Tell me so and it won't happen again)
This looks to be related to bug #134494
*** Bug 139372 has been marked as a duplicate of this bug. ***
Hmm, maybe I should have put it here instead. See comment 37 of bug 134494 for a patch that should fix this problem.
hi, I work with tsch and I was wondering if this problem is specific to this shell or if the problem (at this time) also exist for bash. Has the solution proposed on Comment #7 never been included in xinitrc updates? (xinitrc-4.0.14-1 ?) is this solution specific to bash? or it's supposed to solve the problem for tcsh also? regards. mi.
The aforementioned fix won't be shell specific and a fix has not yet been merged (if it had been this bug wouldn't still be open).
A quick solution is to add: /usr/bin/pkill -u $USER ssh-agent to /etc/X11/gdm/PostSession/Default. This makes the gross assumption all instances of ssh-agent for this user are associated with the gdm login. Usually a pretty good assumption. Comment 37 of bug 134494 looks like a better solution. Comment 19 of bug 134494 gets an "I told you so" for M. Harris
My FC3 box also has the same problem. And attachment 109553 [details] in Bug 134494 solves this problem. Why is this bug not fixed?
> And attachment 109553 [details] [edit] in Bug 134494 solves this problem. > Why is this bug not fixed? Bug #134494 is in "MODIFIED" state, which means that given issue was fixed already (modified) and is awaiting testing by the people who experienced the problem. When you test a bug in MODIFIED state, 4 possible scenarios can arise: 1) The bug still exists. Whoever still has the problem needs to set the bug to "ASSIGNED" state to indicate it still exists, so it will get re-reviewed by a developer again. 2) The bug is fixed. Whoever can confirm the problem is resolved, should set the bug status to "RAWHIDE" or some other appropriate solution, and provide a confirmation comment. 3) Nobody ever responds again. In this case, the bug is assumed by the developers to be fixed. The issue will not get further attention, unless someone sets the bug back to "ASSIGNED" state indicating the problem still exists, along with status feedback. 4) People add comments to the "MODIFIED" bug, but do not ever change the bug state. Since MODIFIED bugs are considered "DONE", they are not tracked and developers generally wont ever see any additional comments or patches added to the bugs. Always update the bug status when updating a bug report, to ensure developers will see the new comments if the problems still exist. I've reviewed the patch and applied it to xinitrc-4.0.15. It will be in rawhide shortly. If there are any regressions, there is a lot of time before FC4 to investigate. Setting status to "RAWHIDE"
Wow talk about extra informative - thanks Mike! As the original reporter of this issue I feel mildly responsible that this was not tidied up sooner. I'm a little unsure as to what I should have done though. I narrowed the issue down and after a hint scoured for (and found) bug #134494 . When someone posted a fix I tested it and reported my results and said it fixed my problem (albeit over in bug #134494). Since I don't have a "super" account (do such things exist for non-Red Hat people) I never had the power to move the other bug out of its modified state because it was not filed by me. What should I have done?