Ubuntu MATE Desktop Loads HUNDREDS of Folders After Install & Keeps Going!

Support & Help Requests
#21

Gordon, sorry, I know some people are fussy re code, and my way has always been to bold any bits not being actually pasted as a block, as in for use by others, or showing the contents of a file or entry, merely because it is so much easier to see when inside a paragraph. OK, rereading that, I see you are saying to mark the file contents as code, not code inside paragraphs, so no worries.

OK, those .desktop files are pretty damned ordinary - worked for YEARS in Gnome and KDE, and having changed the nautilus to caja recently still no problem (as there shouldn't be), except in MATE. So I will give you contents of the single daily_folder.desktop file that runs a script to open the 3 folders (the same script my panel launcher invokes, and which MATE doesn't have a problem with):

[Desktop Entry]
Type=Application
Exec=/home/ozzman/bin/daily_folders
Hidden=false
X-MATE-Autostart-enabled=true
Name[en_AU]=My Daily Folders
Name=My Daily Folders
Comment[en_AU]=Open Android TV, Completed Downloads and Cache folders
Comment=Open Android TV, Completed Downloads and Cache folders
X-MATE-Autostart-Delay=60

I changed the Autostart part to true, but it's actually set to false because MATE can't handle it, even with the minute delay.

#22

I'm also going to try another thing: while that autostart entry (now disabled) was saved at ~/.config/autostart, I'm going to see if putting a copy (enabled) at /etc/xdg/autostart makes any difference. I can't see how it would, but process of elimination and all.

#23

Well, for starters (if it's any solace), I was able to replicate the issue on my own setup, with nothing but the MATE desktop ever installed, so the idea that the problem is caused by desktop residue is cruft. One point for you! :slight_smile: So no, you are not crazy, you are not imagining things, and you should indeed not let anybody tell you otherwise.

One caveat, though: I only was able to replicate the non-stop opening of folders by prepending caja or caja --no-desktop to the Exec line, like this:

Exec=caja --no-desktop /home/ozzman/bin/daily_folders

If you do not add the caja part, the folder doesn't open at all, and an entry in .xsession-errors states that the folder to be opened is not executable (it specifically says Permission denied).

Well, I've been searching (and testing) for over two hours now, and I'm stumped.

There's another article on the Web about this and so far it hasn't been answered:

I've tried pretty much every combination -- I've tried launching Caja without the --no-desktop switch, using xdg-open instead of caja, launching a script which in turn launches Caja, adding an initial sleep statement to the script, adding a sleep statement after launching Caja -- nothing has worked. The sleep statement after launching Caja did not do anything to mitigate the wash of windows -- I mean nothing. The windows came up at their top speed anyway, despite the delay before exiting the script! What the heck?

And, autostarting Pluma on the same folder doesn't cause a wash of windows.

Interestingly, if you disable auto-starting of Caja to draw the desktop background:

gsettings set org.mate.session.required-components filemanager ''

...then you don't get a wash of windows; I get the expected behavior.

If another process is spawned before the script has even exited, then that can mean only one thing: The launched Caja process must be communicating with the "desktop resident" Caja process, and one or the other must be triggering the session manager to rerun autostarted applications.

I think you should file a bug on the MATE Session Manager or Caja. If you point me to the bug report once you've created it, I can add a lot of my findings to the report for you.

Thanks, and I'm sorry I had an attitude yesterday.

3 Likes
#24

Gordon, thanks for your research on this. OK, not sure if I made it clear, but the daily_folders is the script in ~/bin that opens the 3 folders. So the command to execute caja is in the script, not the .desktop file. The contents of the script are:

#!/bin/bash
# Open my daily folders in fixed positions, except for Completed Downloads folder, because you can't use -t and -g together

caja -g 1205x762+75+0 /home/ozzman/Cache
caja -t /home/ozzman/Downloads/Completed "/home/ozzman/Downloads/Completed/4 Kids!" "/home/ozzman/Downloads/Completed/3 Tb"
sleep 2 && caja -g 1205x762+450-0 "/home/ozzman/Android TV"

As I said, this runs totally fine AFTER the autostart programs have loaded, ie: if run manually via my panel launcher (and I just assigned Super+D to run that script). The -g and -t options above are new additions - just run vanilla with 3 folder windows opening MATE can't handle at startup whether together in a script or as 3 standard startup entries. I really can't wrap my head around this, but at least I'm not the only one in the entire known universe experiencing this!

Edit: here is one of the 3 original startup entries via .desktop file in ~/.config.autostart:

[Desktop Entry]
Comment[en_GB]=
Comment=
Exec=caja "/home/ozzman/Android TV" %U
GenericName[en_GB]=Open Android TV Folder in Caja
GenericName=Open Android TV Folder in Caja
Icon=/home/ozzman/Settings/Icons/Programs/Caja-48.png
MimeType=
Name[en_GB]=Open Android TV Folder
Name=Open Android TV Folder
NoDisplay=false
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
X-DBUS-ServiceName=
X-DBUS-StartupType=
X-KDE-SubstituteUID=false
X-KDE-Username=
NotShowIn=MATE

This has worked fine for YEARS in both Gnome and KDE (except I recently changed it from nautilus to caja). The only reason I put it all into a script was for MATE. Though now I have a panel launcher and hotkey for the script, which is handy.

1 Like
#25

Gordon I tried the following from the Linux Mint post:

gsettings set org.mate.session.required-components filemanager ''

... and it did stop the loop of windows opening upon reboot (but I'd put a 20 sec delay, just to be safe). But... it only opened the first folder in the script, for some reason skipping the other two. Yet running the same script via Super+D opened all 3 folders as expected. The only logical explanation left is: gremlins.

#26

OMG, so now I cannot kill Caja using either pkill or killall. The 3 windows I have open are killed but a nanosecond later all 3 appear again! Now I have to figure out how to reset what the following command changed (I'm guessing it's that):

gsettings set org.mate.session.required-components filemanager ''

EDIT: I just had a look in the System Monitor and seems my daily_folders script has apparently become a process. I can kill that, but once I kill Caja, and my 3 folders pop back up, both daily_folders and caja are back in there.

Caja-System-Monitor

I've disabled the script in Startup Applications, so will see how I go after a reboot (can't do that now, as I'm encoding vids).

#27

Please! I wrote that. That command did not come from the Linux Mint post (unless you're talking about some Linux Mint post way, way above that I didn't link to, in which case please pardon my inhospitability).

Use:

gsettings set org.mate.session.required-components filemanager 'caja'

Huh! When we start Caja from a startup application, unless we disable the filemanager component using the gsettings command above, the caja program we start simply informs the running Caja process to open a particular folder -- rather than opening the folder itself.

When I ran Pluma as a startup application, it did not get re-restarted even if Pluma was already running; in other words, I did not run into a deadly feedback loop with Pluma even if Pluma was already running when the startup application ran. Like Caja, Pluma will instruct a running instance of Pluma to open a file instead of opening the file itself, if there is already a running instance of Pluma.

I also notice that if you kill Caja when it's started as a startup application, Caja gets restarted along with your whole script.

I wonder if the common thread here is that Caja gets sent a signal and is killed, and only then does the session manager restart Caja (figuring maybe that the process failed and should be tried again)? I suppose I could see Caja segfaulting after instructing the main, running Caja process to open a particular folder. Could you do me a favor and run:

dmesg | grep -i 'segfault|caja'

...and see if there's any output? If there is no output, then try:

journalctl | grep -i 'segfault|caja'

This might be the cause right there (or maybe not). If it's a segfault or some other abortion by deadly signal, then I might be able to solve the problem.

TIA.

2 Likes
#28

Gordon, hahaha - sorry! I thought the text under the link was an excerpt from the Linux Mint forum post! Which had me scratching my head as to why it wasn't there, haha. OK, both those commands returned nothing: the first immediately gave me back my prompt, the second sat there for a few seconds, so I opened a couple of folders, but then it exited without output.

I ended up disabling the startup script, and while running it manually after logging in produced that same weird thing of only opening the first folder, then opening all 3 once I ran it again, it at least behaved. And while daily_folders was still listed as a process (which had me worried), when I killed Caja it did managed to get killed, at least after doing it 3 times (it reappeared twice, but just the first folder, not all 3, but finally didn't restart itself).

As for the gsettings, I was expecting a new branch (or "key"?) called session to be created in /org/mate/, so I was confused as to why it wasn't, yet it obviously changed something. But I eventually found it at /org/mate/desktop/ (still don't understand that, since the command doesn't have desktop in the path). Once I found that, at /org/mate/desktop/session/required-components/filemanager I could see the default of 'caja' had been set to '', so would be easy to remedy. But thanks for the command - I'll use that to reset to the default before rebooting later today. And I'll see if it makes a difference, as before I had no problem killing Caja, and there was no weirdness in opening all folders in the script. And I've totally given up on trying to autostart them in MATE, which is no big deal since I can do so with a key-combo. But I reckon I should find the official place to report MATE bugs, and bring that whole Caja loop to their attention.

2 Likes
#29

I changed that Dconf setting back to caja, and now when manually running the script, all 3 folders open (no need to run it again because only the first folder opened), daily_folders is no longer sitting in System Monitor as a process, and if I pkill -KILL caja I don't have windows popping back up. I still find it really weird that the script was sitting there as a process, just because it was run at startup - there might be a logical explanation to it, but in 15 years I've never seen anything like that. I'm going to have to start filing some bug reports.

1 Like