Multipla Caja instances During Startup

[willysr]

When logging in to MATE Desktop on some environments, caja may runs multiple times without any ability to being stopped unless it reached the open process limit

Adding --sync to caja.desktop solved this problem

[smikkelsendk]

Have you got any idea why this happens? I have tried this too many times these days (maybe after some fedora 18 update was installed). Usually starts when i go to "Caja: File - Empty Trash".

[willysr]

Have you got any idea why this happens? I have tried this too many times
these days (maybe after some fedora 18 update was installed). Usually
starts when i go to "Caja: File - Empty Trash".

Based on my testing, it was caused when you have other DE installed and
your configuration may be conflicted with others
On my system, i have KDE, XFCE, and E17 installed
If i start it on a system with a clean installation, it won't show up

Willy Sudiarto Raharjo
Personal Blog : http://willysr.blogspot.com
Linux Blog: http://slackblogs.blogspot.com

[tarakbumba]

I randomly get this issue on Mageia 3 and Cauldron with my own prebuild rpms. mate-session-manager opens indefinite caja windows sometimes, i have to kill X. I found that somehow ~/.cache permissions have changed. Thanks to guake i can open drop-down terminal and type caja; see dconf error about ~/.cache.

Killing X or caja from tty won't work. After login caja keeps opening indefinite instances. But changing ~/,cache permissions to the current user and login issue goes away. However i couldn't get a clue about how ~/.cache permissions modified in MATE. This is only MATE issue, i can login into KDE without problems.

Using caja -n, caja --sync or moving caja.desktop from /usr/share/applications to /etc/xdg/autostart won't solve this problem.

[smikkelsendk]

Could it be related to the dconf problems described here: mate-desktop/mate-panel#107 ?

[william20111]

I can confirm I get this problem on MATE 1.6 with OpenSUSE. Keeps opening caja after login, will the try the .cache workarounf but it seems that its only my user that has permissions to the ~/.cache folder anyway.

[mscottnielsen]

I recently had this issue as well (also: nothing wrong with my permissions in ~/.cache). Resolved by modifying caja.desktop to include the --sync option. Once the issue started (I don't know what caused it -- I was fine for a couple weeks on a fresh install before this started happening), the only way I could get a usable system back was by sudo mv -i /usr/bin/caja /usr/bin/caja.bak . Then, I was able to troubleshoot and resolve the issue -- ultimately finding this issue here & implementing the provided work-around.

[infirit]

Documenting stuff from IRC.

[21:59] <MattThirtyTwo> Hello. From now on, I will try to say less stupid things about caja issue #170 and GSettings/DBus/DConf ;)
[22:01] <MattThirtyTwo> I think I start to understand why problems appeared after migration to GSettings in MATE like issue #170.
[22:01] <MattThirtyTwo> The problem is the connection to DBUS
[22:04] <MattThirtyTwo> In caja if you don't wait for the dbus connection to be established, any previous call to  g_signal_connect_swapped on GSettings will erroneoulsy trigger your callback functions .
[22:06] <MattThirtyTwo> But if you postpone the call to g_signal_connect_swapped after function 'ck_call_is_active_cb', then the callbacks won't be triggered anymore.
[22:07] <MattThirtyTwo> Look at the file caja-application.c
[22:08] <MattThirtyTwo> in function caja_application_startup
[22:10] <MattThirtyTwo> g_signal_connect_swapped is used GSettings objects before the dbus connection is finished.
[22:12] <MattThirtyTwo> The error "(caja:14027): GLib-CRITICAL **: g_hash_table_foreach: assertion 'version == hash_table->version' failed" in the logs occurs because DBus has not yet been acquired at org.freedesktop.FileManager1
[22:16] <MattThirtyTwo> The fix is then to postpone all the calls to  g_signal_connect(settings,...) after function 'ck_call_is_active_cb'.
[22:16] <MattThirtyTwo> But this is not easy to do .
[22:17] <MattThirtyTwo> Try "grep -snr g_signal_connect_swapped" on caja source code to see what I mean.
[22:20] <MattThirtyTwo> I haven't found any documentation about this strange GSettings behaviour, so it could be a problem with the way caja uses dbus, I don't know.

Follow up:

[21:52]  <stefano-k> MattThirtyTwo: instead of move on g_settings_* signal calls
[21:52]  <stefano-k> why not simply postpone dbus code?
[22:01]  <MattThirtyTwo> I don't know what would happen if dbus connection is postponed. Maybe libunique is using dbus as well.  The connection to dbus is done only once so it may be easier to start with that and then monitor gsettings.
[22:02]  <MattThirtyTwo> I will try your idea and see what happens.
[22:05]  <Amanas> at caja start up, can we check to see if dbus is initialized and if not wait until it is?
[22:05]  <Amanas> obviously this will slow down initial startup, but could it be an option?
[22:15]  <stefano-k> Amanas: I agree
[22:15]  <stefano-k> MattThirtyTwo: the dbus code for org.freedesktop.FileManager1 is just a feature... no need to start it first
[22:16]  <stefano-k> we could also remove that feature if it is a problem
[22:29]  <MattThirtyTwo> OK, I will try to remove it and see what happens. Caja also opens a dbus connection in do_initialize_consolekit.

More follow up

[18:59]  <MattThirtyTwo> Hello
[19:00]  <MattThirtyTwo> Stefano, after removing the line :   fdb_manager = caja_freedesktop_dbus_new (application);
[19:00]  <MattThirtyTwo> Problem is not fixed
[19:02]  <MattThirtyTwo> The bug occurs more often
[19:04]  <MattThirtyTwo> I will try to wait for all dbus connections to be established before monitoring gsettings.

[tarakbumba]

Still having this issue and no fix yet?

[willysr]

Possible solution is now in master branch via this commit 4f1e756

[willysr]

I think above commit does fixed this issue
closing

[stefano-k]

Distributions could always cherry pick patches

[ghost]

In the meantime this problem can easily worked around by editing the /usr/share/applications/caja.desktop file, changing the X-MATE-AutoRestart value from true to false.

[Hyperion1337]

I had this issue with a fresh install of Ubuntu Mate 64bit 16.4 LTS caused by "antivirus" from the "welcome" software. It is a gui front end for clamAV. The caja add-on is the problem. Once I uninsulated the front end "antivirus" it stopped happening.