Gnome 2.32.1_3 and nautilus-2.32.2.1_1 weirdness on 9.0-RC1

KNOStic

KNOStic

More silliness, more exasperation. Strange behavior on nautilus that's also new with the 9.0-RC1 release since I've got automounting *sorta* working with rebuilds of gvfs and hal from ports.

*IF* a nautilus window is open from "computer:" or "network:" a mysterious second instance of nautilus appears in the System monitor app. The second instance shows that it was started with the "--no-desktop" mode and points to the location started from the associated *.desktop file.

In previous versions on 8.2, the child process didn't create a new process and I cannot for the life of me figure out how this second instance is occurring since it never did before. Worse yet, in default mode, when the window is closed, the child process fails to close unless I configure settings to "exit_with_last_window". When this is done however, automount goes off into bizarro world and it refuses to mount any longer.

After pouring through all of the nautilus sources, I see nothing different or new from the previous versions and am completely lost here. I see no signs of an additional command switch which might be used to modify the .desktop files to recover the previous, older behavior of just one instance of nautilus with children not creating an additional process.

The bizarre symptom of all this is that once a folder view has been opened and the process refuses to die, an automount results in the opening of two views along with an error message claiming:

Code: 
Unable to mount (volume label)
Dbus error org.gtk.Private.RemoteVolumeMonitor.Failed: An operation is already pending

... and then it proceeds to open two folder views of the mounted device. Only one copy shows up in the "Places" menu item on top.

Clearly this second process is messing things up and I can't for the life of me make it stop other than selecting "exit_with_last_window" in gconf. But then mounts no longer work.

Yes, I know, I know "automounting is broken in gnome", but it's SO close to working now aside from this. :(
 
darcsis said:
Weird. I haven't seen this ever on my 9.0 amd64 box. Not for RC1 or RC2.
Click to expand...

Thanks for that! Gets more interesting, and this doesn't make any sense to me at all. Hopefully someone can point me a little deeper. It turns out that when gnome is running, there are two other duplicates on all of the machines here in both 32 and 64.

Two instances of dbus-daemon are running. One is normal, the other was called as:

Code: 
/usr/local/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session

PID 5 points to pagedaemon and PID 7 is pagezero

There are also two instances of gam_server. Neither show signs of any command switches. And there are also two instances of dhclient present, one of them followed by [priv] ... I suspect this is why the two Nautilus' are occurring and at the moment, this is getting MIGHTY confusing. Anyone have any ideas of where to look next? I've built additional copies beyond the default arrangement on the test machines and every one of them is behaving the same way. I'm guessing something is starting another session and for now, have no idea of where to start tracking it down. Weirdness on a stick! :)

Edit: Just got all machines upgraded to RC2 ... same story.
 
OK ... I've finally figured out *what* the problem is, and am hoping someone can point me to where the corresponding code and module might be. It turns out that the
Code: 
nautilus --no-desktop
flag isn't working in nautilus and I really don't want to have to set gconf to force close of the additional nautilus process if there's some way to locate and fix the reason why the
Code: 
nautilus --no-desktop
flag isn't being honored when calling "computer" or "network" or "home" (dot)desktop files. Any ideas?
 
The "aha" moment to this!

It appears as though I've finally figured out what the problem is, now the question is what to do about it. I've tracked it down to libunique and the way nautilus is failing to work with it properly owing to changes in the apparent behavior of libunique.

In the older 8.2 BSD release, libunique creates sockets in /var/tmp/unique subdirectory in the format of:

Code: 
org.provider.progname.:0.0.PID

in 9.0 however, the "latest" version of libunique creates those sockets in the format of:

Code: 
org.provider.progname.:0.PID

So the primary instance of nautilus in 9.0 creates (as example PID's here)

Code: 
org.gnome.Nautilus.:0.1818

And when a device is clicked in "Places" a second instance of Nautilus shows up (and remains rather than being folded back into the original instance as:

Code: 
org.gnome.Nautilus.:0.0.1880

Which results in that second instance since the "unique" has the additional 0 of the older code. The problem is in how unique is creating a new socket instead of recognizing the original one based on how Nautilus and DBus are playing along in the current realm.

So ... can anyone help me figure out how to PR this madness so that it can be rolled into a fix for the final RELEASE ports and packages for 9.0?

The current libunique or Nautilus is apparently caught between two worlds ...

Edit: Unique version is exactly the same in both, yet the behavior is different! Both are unique-1.1.6_2!
 
Oh ... I'm also getting this in dmesg although it's unrelated since I don't get this error on another machine as root:

Code: 
dbus[2297]: [system] Rejected send message, 3 matched rules; type="method_call", sender=":1.42" (uid=1001 pid=2828 comm="nautilus ")
 interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination=":1.4" (uid=0 pid=2684
 comm="/usr/local/sbin/console-kit-daemon --no-daemon ")

Further calls from Nautilus receive similar errors on non-root user. I had originally thought that this was the cause of the problem, but thought I'd include this in case it actually means anything.
 
You must log in or register to reply here.
Back
Top