Bug 2150894
| Summary: | Right-click 'Open in files' does not work on first attempt at first login. | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Vishal Pakolu <vpakolu> | |
| Component: | nautilus | Assignee: | Ondrej Holy <oholy> | |
| Status: | CLOSED ERRATA | QA Contact: | Vitezslav Humpa <vhumpa> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 8.7 | CC: | fmuellner, jadahl, oholy, sbarcomb, tpelka, tpopela, vhumpa | |
| Target Milestone: | rc | Keywords: | Triaged | |
| Target Release: | 8.8 | Flags: | pm-rhel:
mirror+
|
|
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | nautilus-3.28.1-23.el8 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 2162302 (view as bug list) | Environment: | ||
| Last Closed: | 2023-05-16 08:44:12 UTC | Type: | Bug | |
| 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: | 2162302 | |||
|
Description
Vishal Pakolu
2022-12-05 14:52:19 UTC
This happens when "/usr/bin/nautilus --gapplication-service" is not running. The following is recorded in the journal: Dec 07 11:06:59 localhost.localdomain dbus-daemon[2360]: [session uid=1000 pid=2360] Activating service name='org.gnome.Nautilus' requested by ':1.19' (uid=1000 pid=2517 comm="/usr/bin/gnome-shell " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023") Dec 07 11:06:59 localhost.localdomain dbus-daemon[2360]: [session uid=1000 pid=2360] Successfully activated service 'org.gnome.Nautilus' Dec 07 11:06:59 localhost.localdomain gnome-shell[2517]: Error showing file on desktop: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface 'org.freedesktop.FileManager1' on object at path /org/freedesktop/FileManager1 It looks to be a bug in the desktop-icons extensions as the following works even when the service is not running: dbus-send --print-reply --dest=org.freedesktop.FileManager1 /org/freedesktop/FileManager1 org.freedesktop.FileManager1.ShowItems array:string:"file:///home" string:foo (In reply to Ondrej Holy from comment #1) > It looks to be a bug in the desktop-icons extensions as the following works > even when the service is not running: > > dbus-send --print-reply --dest=org.freedesktop.FileManager1 > /org/freedesktop/FileManager1 org.freedesktop.FileManager1.ShowItems > array:string:"file:///home" string:foo But that would bring back https://bugzilla.redhat.com/show_bug.cgi?id=2026622 as far as I can see. Is there a good reason why nautilus only exports the org.freedesktop.FileManager1 interface from the startup vfunc and not dbus_register()? It resides in the startup vfunc since ever. The export of org.gnome.Nautilus interface used to be there as well but later was moved to the dbus_register vfunc. The related commits don't contain any explanation. I don't have any experience with this, but it seems that the right place for that is really dbus_register vfunc. So if you think this needs to be fixed on the Nautilus side, feel free to change the component. Just I wonder how is it possible that the dbus-send cmd works properly... I took look at this again and I finally see what is going on. What the desktop-icons extension really does in RHEL 8 can be reproduced over dbus-send the following way: $ dbus-send --print-reply --dest=org.gnome.Nautilus /org/freedesktop/FileManager1 org.freedesktop.FileManager1.ShowItems array:string:"file:///home" string:foo Error org.freedesktop.DBus.Error.UnknownMethod: No such interface 'org.freedesktop.FileManager1' on object at path /org/freedesktop/FileManager1 $ dbus-send --print-reply --dest=org.gnome.Nautilus /org/freedesktop/FileManager1 org.freedesktop.FileManager1.ShowItems array:string:"file:///home" string:foo method return time=1673335063.362515 sender=:1.82 -> destination=:1.83 serial=95 reply_serial=2 Also, I probably see why the interface is not exported in dbus_register. In the dbus_register vfunc, the org.gnome.Nautilus connection is obtained and thus the /org/gnome/Nautilus interfaces are exported there, but the /org/freedesktop/FileManager1 interface belongs to the org.freedesktop.FileManager1 name that needs to be also acquired and it is not probably desired to synchronously wait there as it could possibly slow down Nautilus startup. However, as per d-feet it seems that it is irrelevant under what connection the interfaces were exported as all the interfaces are listed under both names, which makes me think that we can possibly export the /org/freedesktop/FileManager1 interface over the org.gnome.Nautilus connection and consequently just try to acquire the org.freedesktop.FileManager1 name without actually blocking the startup. Am I right? > Am I right?
Yes, at least as far as I know.
Thanks Ondrej! Reproduced with nautilus-3.28.1-21 and fix verified working with nautilus-3.28.1-22 Indeed, due to the need for updating the current fix to prevent the possible race conditions, I am moving the bug back to assigned so it can be applied. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (nautilus bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2023:2938 |