Bug 169259

Summary: Starting X with 'startx' doesn't run ssh-agent (patch)
Product: [Fedora] Fedora Reporter: Andrew Benham <andrew.benham>
Component: xinitrcAssignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: jgarzik, kekelley, mlists
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-08-18 02:02:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 150223    
Attachments:
Description Flags
Patch to fix none

Description Andrew Benham 2005-09-26 09:30:34 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.10) Gecko/20050909 Fedora/1.0.6-1.2.fc4 Firefox/1.0.6

Description of problem:
If one has a system which starts in run level 3, and one uses 'startx' to start 'X', then the ssh-agent isn't run.

Version-Release number of selected component (if applicable):
xinitrc-4.0.18.1

How reproducible:
Always

Steps to Reproduce:
1. Boot machine to run level 3
2. Run 'startx'
3. Once the desktop is up, run "ssh-add -l" in a shell
  

Actual Results:  Error: Could not contact agent

Expected Results:  No output (unless keys have been loaded into the agent)

Additional info:

Comment 1 Andrew Benham 2005-09-26 09:31:52 UTC
Created attachment 119251 [details]
Patch to fix

Patch to fix

Comment 2 Mike A. Harris 2005-09-26 19:39:32 UTC
Thanks, will review for consideration for FC5.

Comment 3 Christopher Aillon 2006-01-21 02:18:36 UTC
Triaging for FC5.  Mike, there's a patch here, it would be great to take if you
think its good.

Comment 4 Mike A. Harris 2006-03-07 00:47:28 UTC
The patch will do what it claims to do, however there is a deeper problem
which has bounced back and forth since the first OS release that we started
invoking ssh-agent from X scripts.

We need to ensure that if we invoke ssh-agent during X startup, that we
also shut it down when X shuts down, and that we do not shut ssh-agent down
in X startup if X startup didn't start it up.

In other words, some users start ssh-agent from .bash_profile or elsewhere
manually, and they don't want X shutdown to stop it if they've started it.

The other problem that has come up, is that starting ssh-agent without
shutting it down in X scripts, causes machines to leak ssh-agent processes
over time, more or less at a rate of one per login.

So if we enable ssh-agent, we must ensure that these 2 conditions are met:

1) Do not leave the ssh-agent processes we start running after logout.
2) Do not kill ssh-agent processes started by the user, or prior to X startup
   when shutting down.

There are other bug reports open concerning these I believe.  It is too
late to include a feature patch in FC5 which hasn't had widespread testing
to ensure conditions #1 and #2 above are met, however we will review this
for FC6 development, and also consider it for an FC5 update, once we can
ensure the prerequisites above are met.

Moving to FC6Target

Comment 6 Karl E. Kelley 2006-08-16 15:45:55 UTC
This also happens on Redhat Enterprise 4 with update 4, which was just released.
Starting X with startx does not start ssh-agent.

Comment 7 Kristian Høgsberg 2006-08-18 02:02:20 UTC
Patch committed.  The concerns about not launching ssh-agent if it's already
running is already handled by the code in /etc/X11/xinit/xinitrc-common. By
letting ssh-agent launch the session (as done by the patch), the agent will
automatically shut down once the session exits if it was started from startx.

Nothing but startx sources /etc/X11/xinit/xinitrc, so the patch should be safe,
and anyway, worst case is that ssh-agent starts working correctly in some other
combination.


Comment 8 Kristian Høgsberg 2006-08-18 02:45:45 UTC
*** Bug 159624 has been marked as a duplicate of this bug. ***