GNOME Bugzilla – Bug 569636
doesn't register correctly to the session
Last modified: 2009-02-07 19:51:41 UTC
using GNOME 2.25.5, .xsession-errors has this warning "'seahorse-daemon.desktop' failed to register before timeout" that creates a several seconds idlying during the login since gnome-session waits on the registration or timeout to continue starting things
I can confirm this error message. Do you know what registration is supposed to be occuring? The desktop file just calls seahorse-daemon to be executed.
You should either use GnomeClient in some way, or use the egg smclient code (it's really trivial -- just look at the splash screen in gnome-session, eg).
Short of adding a new command line switch, is there a way to only enable the smclient code when being called from the session startup code? Or does smclient make no difference if seahorse-daemon is launched by DBus automatically later?
It won't harm later. Nearly all GNOME apps use session registering. You can look at what evince does, if you prefer a non-startup app ;-)
It'd be really awesome if seahorse-daemon wasn't started automatically. Less churn on startup, less unused processes. I realize that there are a few users of the key sharing who need this to be started on startup. I've been wondering if we shouldn't split out the key sharing server into a different installable module, or move it to seahorse-plugins. Adam, are you interested in fixing this bug or do you want me to take a stab at it?
I've looked into it and will do it this weekend. Like Vincent said, it's pretty trivial. I'll probably add session support to seahorse while I'm at it.
Created attachment 127681 [details] [review] Doesn't fix I added the libegg smclient files to libegg/ and they build properly, so I checked them in. I then added the same kind of statements to daemon/seahorse-daemon.c but the error message persists. Could this have something to do with the -d flag the desktop file is sending to the process which prevents s-d from daemonizing, thus extending the amount of time until control is returned to the session manager?
Fixed. Thanks to vuntz for the hint why the patch didn't work. 2009-02-01 Adam Schreiber <sadam@clemson.edu> * daemon/Makefile.am: * daemon/seahorse-daemon.c: Register properly with the session manager. Fixes bug #569636
will you roll a tarball this week so users can try the change?
Yeah, I thought Stef was going to roll a 2.25.90 yesterday, but I guess not. I'll try to do it this afternoon.
Sorry. Yes I've meant to. Posting an issue I'm running into on the mailing list with libcryptui docs that were added. If you look up 'gtk-doc' in the dictionary you'll find: gtk-doc: (n) 1. Deep, mysterious, voodoo. 2. An oxymoron, that is, undocumented documentation.
I just made a release. I'm working on seahorse-plugins now.
thank you for rolling the tarball, could any of you also look at bug #570393 or bug #568406 which are gnome-keyring build issues which prevent upgrading to the new version which is required by seahorse now?
the warning and the login delay are still there in 2.25.90
After a reboot and a re-login, I no longer experience the pause or the warning. $ cat .xsession-errors |grep seahorse Have you rebooted after upgrading?
$ cat .xsession-errors | grep seahorse x-session-manager[5441]: WARNING: Application 'seahorse-daemon.desktop' failed to register before timeout the running version is 2.25.90
I did reboot the box several times today
Is there any other debug info you can give me or have a look at daemon/seahorse-daemon.c and tell if anything's missing? I just logged out and back in and couldn't replicate the problem again. I'm running ibex with the latest gnome-keyring and seahorse from trunk, but I'm not quite ready to upgrade to jaunty as this is my working laptop and I'm trying to finish my dissertation.
not sure how to debug this, does anybody still get the issue on GNOME 2.25?
the svn change seems pretty simimar to the change you copied to the bug which was not working what was the change vuntz suggested?
He suggested removing the call to g_option_context_parse because the option context was already passed to gtk_init_with_args.
Vincent any idea how to get debug informations about session registration?
(In reply to comment #22) > Vincent any idea how to get debug informations about session registration? Err, right now, no idea what's wrong nor how to debug this. I suggest putting evince instead of seahorse-daemon in the .desktop file to see if you get the same result. I might have more time to look at that after FOSDEM...
changing the desktop command to evince workaround the timeout error so it seems to be a seahorse issue
Go into the sessions and instead of seahorse-daemon -d. Put just seahorse-daemon.
changing the command to seahorse-daemon fixes the issue
Great, the reason that switch was in the desktop file was because the daemon when it's daemonized (forked) wasn't receiving gconf notifications properly. Could you test if it is or not by selecting in the preferences, "When encrypting ,always include myself as a recipient", rebooting to make sure the daemon picks up the setting, encrypt a file to someone else and make sure you can decrypt it, then change the setting, encrypt a different file to someone else and make sure you can't decrypt it?
I don't want to reboot now but I will try later and comment on how it works, but it's working in the current version for you?
btw what does the seahorse-daemon does exactly? is there really a need to run the agent and that for all the users?
I haven't tried it yet. The daemon provides the DBus interface, which gets auto-started when the first DBus call is made if it's not already running. The DBus interface is largely used by libcryptui and the plugins in seahorse-plugins. The daemon also provides the avahi/bonjour key server which I believe is why it is auto-started. If the keyserver were disabled by default, then the daemon wouldn't need to be autorun at login for everyone. I'm not sure that it would get turned on by too many users if that were the case though because I'm not sure too many users know it exists. I could be wrong though.
I just realized as I went to test this that because of the regressions it can't be tested at the moment. I'll add the blocks below.
The only users for whom autostarting seahorse-daemon is useful are those who use the key sharing capability, and want to make it available when they log in. I believe someone added the autostart for that reason. But in my opinion the key sharing should be a separate daemon. Perhaps even distributed separately. It has precious little in common with the rest of seahorse, and could be developed on its own.
the new gnome-session allow to start autostart files depending on the value of a gconf key, that could be used there, that's a different request though and I will open a new bug about this one
Nice. Good plan.
*** Bug 570840 has been marked as a duplicate of this bug. ***
On my machine, I was able to verify the daemon without the -d flag listening to changed gconf keys. Please test and let us know if that isn't widely true. 2009-02-07 Adam Schreiber <sadam@clemson.edu> * daemon/seahorse-daemon.desktop.in.in: Only autostart the daemon when sharing is enabled. Fixes bug #570773