Bug 138747 - ssh-agent process continues to run after user logs out
ssh-agent process continues to run after user logs out
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xinitrc (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
: Triaged
: 139372 (view as bug list)
Depends On:
Blocks: FC4Blocker
  Show dependency treegraph
 
Reported: 2004-11-10 18:23 EST by Sitsofe Wheeler
Modified: 2007-11-30 17:10 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-21 12:51:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sitsofe Wheeler 2004-11-10 18:23:39 EST
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...
Comment 1 Oswaldo Morizaki 2004-11-19 02:16:06 EST
I got the same problems.
I noticed that after logout SSH_AGENT_PID is unset, but it's set when
you're logged. 
Comment 2 Sitsofe Wheeler 2004-11-29 03:34:52 EST
Further to what was reported in bug 139372 I tested this in GNOME, KDE and XFCE.
All three desktops show this problem.
Comment 3 Sitsofe Wheeler 2004-12-01 13:12:53 EST
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...
Comment 4 Sitsofe Wheeler 2004-12-01 13:20:59 EST
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)
Comment 5 Sitsofe Wheeler 2004-12-10 15:59:55 EST
This looks to be related to bug #134494
Comment 6 Mark McLoughlin 2004-12-14 05:28:18 EST
*** Bug 139372 has been marked as a duplicate of this bug. ***
Comment 7 Paul Iadonisi 2005-01-10 08:40:39 EST
Hmm, maybe I should have put it here instead.  See comment 37 of bug
134494 for a patch that should fix this problem.
Comment 10 miji piji 2005-03-02 21:06:25 EST
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.


Comment 11 Sitsofe Wheeler 2005-03-03 03:39:40 EST
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).
Comment 12 Bob Arendt 2005-03-11 14:41:34 EST
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
Comment 13 Takanori MATSUURA 2005-03-13 21:22:39 EST
My FC3 box also has the same problem.

And attachment 109553 [details] in Bug 134494 solves this problem.
Why is this bug not fixed?
Comment 14 Mike A. Harris 2005-03-21 12:51:48 EST
> 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"
Comment 15 Sitsofe Wheeler 2005-03-21 13:49:47 EST
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?

Note You need to log in before you can comment on or make changes to this bug.