Red Hat Bugzilla – Bug 138747
ssh-agent process continues to run after user logs out
Last modified: 2007-11-30 17:10:54 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
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):
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.
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
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
exec ssh-agent /etc/X11/xinit/Xclients
[ -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
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.
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?
is this solution specific to bash? or it's supposed to solve the problem for
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
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]  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
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?