Bug 351884 - Multiple instances of ssh-agent and seahorse interfering with one another.
Summary: Multiple instances of ssh-agent and seahorse interfering with one another.
Status: RESOLVED DUPLICATE of bug 383353
Alias: None
Product: openSUSE 10.3
Classification: openSUSE
Component: GNOME (show other bugs)
Version: Final
Hardware: Other openSUSE 10.3
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Hans Petter Jansson
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-05 11:20 UTC by Carlos Robinson
Modified: 2008-05-28 19:14 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
requested ~/.gnome2/session file (14.42 KB, application/octet-stream)
2008-01-08 00:26 UTC, Carlos Robinson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Robinson 2008-01-05 11:20:59 UTC
ps afx output excerpt:

 5537 ?        S      0:00  \_ /usr/sbin/gdm
 5541 tty7     Ss+   19:18      \_ /usr/bin/X :0 -audit 0 -br -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7
 5570 ?        Ssl    0:01      \_ /usr/bin/gnome-session
 5615 ?        Ss     0:00          \_ /usr/bin/ssh-agent /bin/bash /home/cer/.xinitrc

 5726 ?        Ssl    0:39 seahorse-agent --sm-config-prefix /seahorse-agent-V2r6aH/ --sm-client-id 11c0a8010c000119470880700000205230004 --screen 0
 5735 ?        Ss     0:00 seahorse-agent --sm-config-prefix /seahorse-agent-xqyZu2/ --sm-client-id 11c0a8010c000119470830500000184410000 --screen 0
 5757 ?        Ss     0:00 /usr/bin/seahorse-agent
 

As you see above, there is one ssh-agent (probably started by .xsession), and three instances of seahorse-agent, interfering with one another. Till I killed some of them at random I was unable to ssh out. I guess only one of them should be running, and I submit as a bug that they are started by something/somewhere unknown. The end result is that ssh passwords are not cached.

cer@nimrodel:~> less .xsession
cer@nimrodel:~> set | grep SSH_
SSH_AGENT_PID=5615
SSH_ASKPASS=/usr/lib/ssh/x11-ssh-askpass
SSH_AUTH_SOCK=/tmp/ssh-cBjhK5570/agent.5570

Further, I believe they are not all of them killed on session close: I have to open a text terminal and check what processes are still running as the user that exited, and kill them manually, every time (several programs/daemons).
Comment 1 Mark Gordon 2008-01-07 17:40:11 UTC
I'm unable to reproduce this problem.
Comment 2 JP Rosevear 2008-01-07 18:30:01 UTC
Same here, I have not seahorse-agent running.  Perhaps you need a certain configuration for this.
Comment 3 Mark Gordon 2008-01-07 19:29:55 UTC
I added it to .xinitrc; I'm not sure how it's being started for the reporter.  As the ps output indicates, ssh-agent is started by gnome-session, so that much is no mystery.  Maybe it's in the session.

Please attach ~/.gnome2/session
Comment 4 Carlos Robinson 2008-01-08 00:24:42 UTC
Seahorse-agent is started, I think, because once I started the seahorse program, went to preferences or somewhere and said I wanted the agent. That must have been months ago, so I don't remember the details. At least, in 10.3 I can run seahorse without it crashing, it is an improvement.

And you are right, there are entries in ~/.gnome2/session (I'll attach it complete later):

5,Program=seahorse-agent
5,CurrentDirectory=/home/cer
5,CloneCommand=seahorse-agent --sm-config-prefix /seahorse-agent-V2r6aH/ 
5,RestartCommand=seahorse-agent --sm-config-prefix /seahorse-agent-V2r6aH/ --sm-client-id 11c0a8010c000119470880700000205230004 --screen 0 

12,Program=seahorse-agent
12,CurrentDirectory=/home/cer
12,CloneCommand=seahorse-agent --sm-config-prefix /seahorse-agent-xqyZu2/ 
12,RestartCommand=seahorse-agent --sm-config-prefix /seahorse-agent-xqyZu2/ --sm-client-id 11c0a8010c000119470830500000184410000 --screen 0 

19,RestartCommand=/usr/bin/seahorse-agent 


So... is that the culprit of the double seahorse-gent?

[...]

I go to "sessions" in the gnome control center, and in the "startup programs" tab the "seahorse agent" click box is ticked. I believe I ticked it there the first time.

I just did a grep search (mc) for the string "seahorse-agent", and I found another entry, in "./.config/autostart/seahorse-agent.desktop":

Exec=/usr/bin/seahorse-agent


What I still don't understand is how I got three 'seahorse-agent' instances running. My hypothesis is that after I configured it to start, when some other time I saved the session, from then on, the session managerwhatever also starts it: those would be the two entries with parameters (that would be a bug, I think: save session should not save a program that is defined to start somewhere else - or viceversa). 

There still remains unexplained the other agent without parameters... also save session?. Plus the ssh-agent, which must started by the script ~/.xsession, although it is set to "no":

# If ssh is configured and ssh-agent is wanted set "yes"
#
usessh="no"

...

# 
# Run ssh-agent only if ssh is configured and avaliable.
#
sshagent="no"
if test "$usessh" = "yes" -a -d $HOME/.ssh ; then
    type ssh-agent > /dev/null 2>&1 && sshagent="yes"
fi



There is also an error in .xsession-errors:

(gnome-panel:18228): libgnomevfs-CRITICAL **: gnome_vfs_monitor_add: assertion `text_uri != NULL' failed
can't lock memory: Cannot allocate memoryWARNING: not using secure memory for passwords
** Message: Another GPG agent already running

** Message: Another GPG agent already running

** Message: Another GPG agent already running


** (seahorse-agent:18334): WARNING **: couldn't connect to SSH agent at: /tmp/ssh-IoNF18156/agent.18156: Connection refused

** (seahorse-agent:18334): WARNING **: couldn't contact SSH agent. Cannot proxy SSH key requests.
kbuildsycoca running...

** Message: drive = 0
** Message: volume = 0
** Message: drive = 0
** Message: volume = 0
Nautilus-Share-Message: REFRESHING SHARES




Comment 5 Carlos Robinson 2008-01-08 00:26:08 UTC
Created attachment 189650 [details]
requested ~/.gnome2/session file
Comment 6 Hans Petter Jansson 2008-04-17 05:32:34 UTC
Carlos, I think you're right:

Your "run on startup" instance makes you end up with N+1 seahorse-agents, where N is the number of agents in your session. If you save your session with 0+1 agents, the next time you log in you'll have 1+1. Then if you save the session again, that number will increase to 2+1.

You really shouldn't have to manually run seahorse-agent on startup. I think we need to remove it from that list and make sure it starts automatically. That seems to be what we're doing in openSUSE 11.0.
Comment 7 Hans Petter Jansson 2008-04-17 05:34:07 UTC
Carlos, can you verify that this is indeed what's happening?
Comment 8 Carlos Robinson 2008-04-20 13:02:33 UTC
Ok, I'm in factory, gnome session.

ps afx | less

does not show anything named "seahorse" running. 

  The main_menu/System/security shows only the kde key management program,
  not the gnome one. The main_menu/utilities/security shows them both.
  Another usability issue (inherited form long ago).

I start "seahorse" from the menu: I go to edit preferences, pgp passphrasses tab, and it reads:

   "A supported PGP passphrase caching agent is not running"

But I don't see how to start seahorse-agent, or I don't remember where it should be. Help is no help at all, because it fails to start (known bug).

Mmm, seahorse chrashed when creating an ssh key and dragging a window. Sorry, dumped the crahs log. The key was created anyway.

I don't see a gnome session properties whatever anywhere in the main menu :-?

I don't know/remember how to say I want an agent running :-?

I'll start it from a shell, then.


cer@minas-morgul:~> seahorse-agent &
[1] 24573
cer@minas-morgul:~> ** Message: Another GPG agent already running


[1]+  Done                    seahorse-agent

cer@minas-morgul:~> ps afx|grep -i agent
 3446 ?        Ss     0:00          \_ /usr/bin/ssh-agent /bin/bash /etc/X11/xinit/xinitrc
 3445 ?        Ss     0:00 /usr/bin/gpg-agent --sh --daemon
24595 pts/1    S+     0:00      \_ grep -i agent
24583 ?        Ss     0:00 seahorse-agent

So, seahorse-agent is running now.

However, when I go to seahorse/preferences/pgp passphrasses, it still claims there is not agent running.

If I try to exit the session, I'm not prompted to save it, nor do I see a menu entry for it. There are some usability issues with gnome, this bug has been reported ages ago...

So I manually run "gnome-session-save" form a terminal. It doesn't report anything. I'll close the session and report back.

Comment 9 Carlos Robinson 2008-04-20 13:24:21 UTC
Before starting the X session, I had a look in text mode. There were two programs of user "cer" still running, that gnome log-out did not kill:

cer       3445  0.0  0.0   3804   780 ?        Ss   13:36   0:00 /usr/bin/gpg-agent --sh --daemon
cer       3470  0.0  0.3  25612  3548 ?        Ssl  13:36   0:00 /usr/bin/pulseaudio --log-target=syslog -Lmodule-esound-compat-spawnfd fd=19


So, there was another "-agent" running and I didn't see it. I kill both programs and log in gnome again. Sure enough, there are two agents running now:

root     24768  0.0  0.1   4420  2008 ?        S    15:03   0:00  \_ -:0              

cer      24919  0.2  1.3  91108 13480 ?        Ssl  15:09   0:00      \_ /usr/bin/gnome-session

cer      24992  0.0  0.0   5612   676 ?        Ss   15:09   0:00          \_ /usr/bin/ssh-agent /bin/bash /etc/X11/xinit/xinitrc

cer      25505  0.0  0.0   3064   748 pts/1    S+   15:14   0:00          |       \_ grep -i agent

cer      24991  0.0  0.0   3804   780 ?        Ss   15:09   0:00 /usr/bin/gpg-agent --sh --daemon

cer      25164  0.0  0.7  85088  7680 ?        Ss   15:10   0:00 seahorse-agent --sm-config-prefix /seahorse-agent-Ax1kMC/ --sm-client-id 117f000002000120869585500000033720025 --screen 0



The gpg-agent is started - no I don't know by whom. Probably by the scripts starting the X session. Grep does not find it in my home.
The ssh-agent is started by gnome-session
The seahorse-agent I suppose is started because session was saved.

And seahorse claims there is no agent active. Go figure.


So I think the bug is exactly as it was in 10.3.

Can I do more testing?

Comment 10 Vincent Untz 2008-05-28 19:14:05 UTC
Should be better now that bug 383353 is fixed :-)

*** This bug has been marked as a duplicate of bug 383353 ***