After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 727622 - Could not register the application: Timeout was reached
Could not register the application: Timeout was reached
Product: glib
Classification: Platform
Component: gio
Other Linux
: Normal major
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Reported: 2014-04-04 18:14 UTC by Aaron Paden
Modified: 2018-05-24 16:23 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Aaron Paden 2014-04-04 18:14:51 UTC
I can't start nautilus from the overview. My cursor will start the spinning animation for a few seconds, and then nothing. I can open nautilus fine from the terminal.

Looks like every time I try: I get the following messages from Logs in this order:
dbus-daemon: "The EBookBackendGoogle instance for "Contacts" is shutting down."
gnome-session: "JS LOG: Recieved error from DBus search provider nautilus.desktop: Gio.IOErrorEnum: Timeout was reached"
gnome-session: "JS LOG: Recieved error from DBus search provider org.gnome.Documents.desktop: Gio.IOErrorEnum: Timeout was reached"
gnome-session: "JS LOG: Recieved error from DBus search provider bijiben.desktop: GIO.IOErrorEnum: Timeout was reached"
gnome-session: "JS LOG: Recieved error from DBus search provider org.gnome.Photos.desktop: Gio.IOErrorEnum: Timeout was reached"
nautilus: "Could not register the application: Timeout was reached"
gnome-session: "Window manager warning: Log level 16: AT-SPI: Error in GetItems, sender=org.freedesktop.DBus, error=The name :1.51 was not provided by any .service files"

Obviously most of these are not directly related to nautilus, but these messages pop up every time I try to launch it.

I'm using the Arch packages is [gnome-unstable], if that matters. Also something that occurred to me; I run Linux from a USB 3.0 external HDD, so file IO is probably slower than most machines. IDK if that is what is causing these timeouts or not. Might be a red herring.
Comment 1 Aaron Paden 2014-04-07 14:55:43 UTC
So it looks like the 'Could not register the application' error message happens in src/nautilus-application.c:nautilus_application_local_command_line because g_register_application is failing.

Looking at the docs, I think this is pointing to being a dbus problem rather than strictly a nautilus problem. That would make sense given all the dbus errors I'm getting in the logs.

It does look like the Could not register error is intended to be fatal, but this is not actually causing nautilus to crash. The nautilus process continues to run. Actually, I tried launching nautilus from the overview today, and I forgot to kill off the process. A window did pop up, about 20 minutes later. Weird.
Comment 2 Michael Vorburger 2015-02-14 11:35:49 UTC
Affecting me too, regularly... $5 offered on ;-)
Comment 3 Michael Vorburger 2015-02-14 11:36:26 UTC affects 7 people
Comment 4 Aaron Paden 2015-03-26 04:18:49 UTC
I'm still having issues in 3.16 where nautilus fails to open for several minutes after selecting it from the overview. I'm **am** getting timeout errors in the logs, but **not** "Could not register the application" errors, so I can't confirm that this is even the same bug...
Comment 5 Andrew 2015-04-06 11:07:29 UTC
Also hit this "Could not register the application: Timeout was reached",
but after some time (about 3 min) nautilus opened it's window.
Comment 6 Matthias Clasen 2015-04-06 12:18:56 UTC
This is not a nautilus bug. Your session setup is broken, somehow.
Comment 7 Andrew 2015-04-06 12:27:59 UTC
Well, maybe....
I've found out that it was caused (at least it looks like)
by network share (smb://) which disappeared from network, but still was seen in nautilus as mounted.

Where and how I can see a real cause?
Comment 8 Aaron Paden 2015-04-06 15:11:52 UTC
(In reply to Matthias Clasen from comment #6)
> This is not a nautilus bug. Your session setup is broken, somehow.

As far as I've seen, this doesn't effect any other application in a user-facing way. It'd be nice to figure out why my session is broken, but even if I can't maybe nautilus could handle the issue more gracefully.
Comment 9 Aaron Paden 2015-10-13 01:57:03 UTC
Still running into this on 3.18. This is on a two-day old install of Arch with no network mounts at all.
Comment 10 Aaron Paden 2015-10-13 02:17:42 UTC
Just happened in another application for the first time that I've noticed: gnome-documents.

I didn't think of this before, but if this is indeed a bug in GApplication, this should probably go in GIO.
Comment 11 Matthias Clasen 2015-10-13 18:31:28 UTC
This bug does not look related to GApplication to me, and I don't think that moving it to GLib will bring it closer to a resolution.
Comment 12 Aaron Paden 2015-10-14 01:07:47 UTC
That's the best I got. You got any ideas?
Comment 13 antonin.chambolle 2015-10-18 06:51:41 UTC
The same happens to me. It IS a bug. And I think as observed by many, it happens when remote file systems are mounted by Nautilus (smb , sftp:// for me...)
So in that case there is maybe some wrong statement in the program which makes Nautilus wait it has some communication with these remote machines before opening a window, even if it is asked to display a different folder (but this might not be the right explanation: as I presently use a key to log on the remote system). It would be very nice to solve this problem, as it is really painful to work without Nautilus... (particularly to move things around different computers with sftp, for instance...)

ps : after 10' and connecting on the remote machine with ssh on a terminal (don't know if it helped) a window eventually opened...
Comment 14 Aaron Paden 2015-10-18 14:46:42 UTC
Well I don't know that Clasen is saying that this isn't a bug, just that he thinks the bug is somewhere else in the stack. Without further information, I've got no idea where else to put it, though.

Also, the remote filesystem thing **may** be a red herring since I've most recently run into this on a new install without ever mounting any remote filesystems. Also, I've recently run into the same symptoms when trying to start gnome-documents, though only once so far. It's possible that this is simply code that nautilus and gnome-documents share, I don't know.
Comment 15 antonin.chambolle 2015-10-21 07:57:03 UTC
Just a small comment this morning: I closed my laptop yesterday night just after saving files on a remote machine using "save a copy" in evince (I assume this goes through Nautilus but am not certain?), and this morning I cannot open Nautilus again. It seems really linked to connecting on a remote system...
One issue is that the message "could not register the application" is not very clear.
by the way : also gthumb does not work. evince works but stalls when asked to open/save a file. basically every application which goes through the file manager to access the files has problems. That is beginning to be a very big issue.
Comment 16 Boris Egorov 2015-10-26 03:37:14 UTC
This, or very similar bug, affects me. nautilus takes VERY long time to start (like someone mentioned, 10-20 minutes) when selected in overview. Can't start it from terminal either:

    $ nautilus
    (nautilus:6232): GLib-GIO-CRITICAL **: g_dbus_interface_skeleton_unexport: assertion 'interface_->priv->connections != NULL' failed

    (nautilus:6232): GLib-GIO-CRITICAL **: g_dbus_interface_skeleton_unexport: assertion 'interface_->priv->connections != NULL' failed
    Failed to register: Timeout was reached

It is really annoying. Please provide any way to trace it down.
Comment 17 Aaron Paden 2016-04-08 00:15:42 UTC
I haven't seen this yet in 3.20. Has anyone else?
Comment 18 Carlos Soriano 2016-04-08 13:31:09 UTC
I can see it sometimes, but just when developing in jhbuild, not in the installed instance.
Comment 19 GNOME Infrastructure Team 2018-05-24 16:23:55 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: