Description of problem:
called caja from menu of mate 1.6.0
Version-Release number of selected component:
runlevel: N 5
var_log_messages: May 10 09:02:07 localhost abrt: Saved core dump of pid 2352 (/usr/bin/caja) to /var/tmp/abrt/ccpp-2013-05-10-09:02:06-2352 (116568064 bytes)
Thread no. 1 (10 frames)
#5 button_data_file_changed at caja-pathbar.c:1859
#11 caja_file_emit_changed at caja-file.c:7391
#12 caja_directory_emit_change_signals at caja-directory.c:809
#13 emit_change_signals_for_all_files at caja-directory.c:259
#14 async_state_changed_one at caja-directory.c:309
#15 g_hash_table_foreach at ghash.c:1526
#16 async_data_preference_changed_callback at caja-directory.c:321
#17 g_cclosure_marshal_VOID__STRING at gmarshal.c:964
#22 g_settings_real_change_event at gsettings.c:288
#23 ffi_call_SYSV at ../src/x86/sysv.S:65
Potential duplicate: bug 905232
Created attachment 746239 [details]
Created attachment 746240 [details]
Created attachment 746241 [details]
Created attachment 746242 [details]
Created attachment 746243 [details]
Created attachment 746244 [details]
Created attachment 746245 [details]
Created attachment 746246 [details]
Created attachment 746247 [details]
Opened issue with upstream.
Did this issue sill exits with current mate-file-manager-1.6.2-1.fc19 from updates-testing?
This happened with:
immediately after I logged in, after rebooting.
I had to reboot, because I had an attack of the x-caja-desktop's after a few hours.
The 2 reboots prior to that, were caused by attacks of the x-caja-desktop's, after about a day, and several days respectively.
I am running Fedora 19
32 GB RAM
Please re-open this bug.
Why do you think this is the right place for your issue?
abrt told me, and I always believe what my computer says! :-)
I suspect that the hash that abrt generated matched this bug, as 'show log' gave:
"--- Running report_uReport ---
A bug was already filed about this problem:
I'll make a comment on the bug you suggested.
Than please add the necessary files which are created by abrt, like backtrace, etc, tho help us.
You will find those in /var/tmp/abrt/ .
not anymore, sorry
Don't understand me wrong but i wanna be shure that the issue is the same from the original reporter, without a backtrace + other files i can't confirm that.
The orginal reporter didn't say anything about the x-caja-windows issue.
So pls, don't delete the report in aprt if it ocours again and see for the folder in /var/tmp/abrt/ .
If there is no backtrace ask me how to create them.
Any information is welcome to fix this MATE MOST WANTED!
No worries mate! :-)
I can assure you, that I too very much want these attacks of x-caja-desktop's terminated.
The only thing I can add, is that in each case I was up-to-date wrt yum updates, within a few hours - I do a yum update at least once a day.
Created attachment 800198 [details]
An attack of x-caja-desktop's started over an hour after logging in after a reboot, and had done a yum update which included the new kernel 3.11.2.
I'll keep the other files, so if you want any of them, please let me know.
Created attachment 800199 [details]
I'll load any files that I think might be useful, let me know if you need any more...
Created attachment 800200 [details]
Created attachment 800201 [details]
Created attachment 800203 [details]
open file descriptors
Created attachment 800212 [details]
proc pid status
Created attachment 800213 [details]
X session errors
$ rpm -qa |grep mat
The 'attack' happened again spontaneously, several hours into a session. I tried killing the caja process, but it was only restarted again immediately by mate-session, and immediately began to open an infinite number of windows again every time.
Even after going into the MATE Preferences menu and disabling Caja in the session management options, it was still be automatically restarted.
Eventually I sent SIGSTOP to caja to prevent it from opening any more windows. I was then able to apply the workaround that has been suggested in:
I then killed caja again, it restarted, this time without an attack. So it looks like this worked around the issue.
This might be unrelated, but a few minutes ago I noticed that mate-panel was using over 100% CPU, and its menus were not responding. Killing mate-panel, simply got another instance of mate-panel with the same behaviour.
Thanks for your information.
A correction to Comment 19, it was the 3.11.1 (not the 3.11.2) kernel!
Linux saturn 3.11.1-200.fc19.x86_64 #1 SMP Sat Sep 14 15:04:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
I send your informations to upstream.
The problem with mate-panel in Comment 27, has a solution mentioned in:
(from comment #27)
> windows. I was then able to apply the workaround that has been suggested in:
About 10 days later, I had another attack of the x-caja-desktop's!
The 2 files mentioned still had 'Exec=caja -n --sync' lines (I just checked). So looks like adding '--sync' is either, only a partial answer, or at least not as relevant as hoped for!
It seems that we have 2 issues.
1. x-caja-windows at session startup
2. x-caja-windows during session.
I think, and also one mate dev, that the '--sync' workaround helps for (2).
So was the last attack at session startup or in a running session?
A massive attack of x-caja-desktops, I also noted mate-panel going to 100+% & being unresponsive.
cmdline: caja -n
reason: Process /usr/bin/caja was killed by signal 6 (SIGABRT)
runlevel: N 5
Note that: The attack of Comment #32 was in the same session as Comment #27, but several days later - AFTER '--sync' had been applied to the 2 files.
This time I rebooted.
mate-file-manager-1.6.3-1.fc19 from updates testing should fix the attack of the x-caja-desktop window. Pls can you test this update and leve karma at
I have twice had caja crash over the last day or so, but no sign of any attack of x-caja-desktop's!
Abrt says the issue has already been reported, and gives this URL as evidence!
When I attempt to start caja in a terminal, I get lots of error messages like:
(caja:21970): dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied. dconf will not work properly.
The system had been up for over a day, and my session had been up almost as long. Plus I had sucessfully used caja many times.
Is there any work-around?
Are there any more diagnostics I can provide?
Linux saturn 3.12.7-200.fc19.x86_64 #1 SMP Fri Jan 10 15:32:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
crashed again, when I went to delete a file
(note previous crash was with kernel 3.12.6, since the I've applied a yum update)
I did closed this bug because of 'x-caja-window' issue is fixed.
So your new issue is a different bug.
For the unwriteable /run/user/1000/dconf/user we could nothing do, because it is a systemd bug.
We all waiting for systemd guys that they apply their commits from systemd devel to fix this.
If you run in this issue check/and correct permissions for /run/user/1000/dconf/.
Could you please open a new report for the new issue?
see also https://bugzilla.redhat.com/show_bug.cgi?id=1044542
same prob with unwriteable /run/user/1000/dconf/user
(In reply to Wolfgang Ulbrich from comment #39)
> @ Nivag
> I did closed this bug because of 'x-caja-window' issue is fixed.
> So your new issue is a different bug.
> For the unwriteable /run/user/1000/dconf/user we could nothing do, because
> it is a systemd bug.
> We all waiting for systemd guys that they apply their commits from systemd
> devel to fix this.
> If you run in this issue check/and correct permissions for
> Could you please open a new report for the new issue?
I suspect my basic problem is covered by
so is there any point in raising another issue on this?
More significant is that abrt is saying the issue has been reported, yet I would have thought that this is a distinctly different problem to the attack of x-caja-desktop's! Not sure how to characterise that in a bug report for abrt, or even to search to see if it has been raised against abrt!
Thanks for the work-around.
Thanks for info.
I'm not shure that abrt is working correct in this point, because yesterday a abrt alarm in rawhide pointed me to a closed bug in f19 which has a complete different cause ;)
Anyway, you're are the only active supporter for this issue and you issue is currently the dconf directory.
So i will move this report to https://bugzilla.redhat.com/show_bug.cgi?id=753882
*** This bug has been marked as a duplicate of bug 753882 ***