Proposal: recovery menu for minimenu (aka breaking the crash loop)

[_jr_]

If you like skeezix's minimenu (and even if you don't), you possibly already experienced minimenu crashing in an endless loop on startup.

Besides trying to fix the crash bugs (four patches for last selected app and category mapping related crashes are contained in the attached zip), I have created a mmwrapper patch to start another program when minimenu crashes. This is currently a simple shell script using zenity to start a Terminal, a different ui, or shutdown the pandora. I want to get some feedback before pestering skeezix.

Please download mmtest.zip and extract it anywhere. (It contains mmwrapper/mmenu compiled from the git commit indicated in the file HEAD plus the included patches, the actual failure mode script mmfail.sh and two test wrappers.)

To just test the recovery part without having to crash your carefully configured minimenu first run mmtest. This uses /bin/false instead of minimenu simulating a startup crash. Note that shutdown and switch in the recovery menu will actually shutdown and switch your gui.

To test it with minimenu (containing the patches mentioned above) included run mmtest.mmenu. It should work normally including starting PNDs. If it crashes it should run the recovery script.

If you like taking risks you can test this as your default ui by putting the full path to mmtest or mmtest.mmenu into .xinitrc in your user's home directory in the line that begins with

DEFAULT_SESSION=...

To change it back just use the Pandora startup configuration scripts to set the default gui (or edit .xinitrc yourself). I've run this for a while and it seems to work, but YMMV.

I'd like to hear your opinion.

Thanks for helping me with this!

edit: updated attachment; now contains mmenu with my patches applied

edit 2014-07-10: updated attachment

 

[skeezix]

I actually built something years ago, since its really simple, but never got around to testing it.

ie:

In mmwrapper, just store the time before launches, and a counter .. if number of launches within a one minute timeframe (say) is > 5 or something, assume its looping and then do..

- new flag for mmenu so it ignores configs, or if no time..

- just have mmwrapper rename/delete any local configs (so that global default gets used)

Used to be these crash loops (not usualy crashes ,just mmenu quitting itself) were bad skins or hacked configs; but theres probably some way to get it to happen

ie: Doesn't strike me as a UI is needed -- people who get into this position usually don't know what to do (a terminal won't help.)

Usually ejecting the SD will solve the problem so the PAndora isn't 'dead' until they hit the forum, but people may panic and not think of it.

As such, I always figured the best behaviour is some automatic 'make it work' logic like above, even if it causes you to lose your config settings (not hard to set them again; and they were broken anyway, somehow.)

What do you think?

jeff

 

[_jr_]

My proposal is much simpler than that and does accomplish less. It just helps the user getting out of the crash loop into another ui or shutdown. The Terminal is just an added bonus, and minimenu has it too


Recovery is a separate program because it keeps mmwrapper small and is actually the most trivial change I could think of (after all, running programs is what mmwrapper is already good at). Crash detection is also maximally simple: if the command left by minimenu upon exit isn't usable, assume something did go wrong.


This doesn't change minimenu itself, but an option to ignore some or most config files is a really good idea.


What do you think of the good old 'create magic file on start and delete after successful initialization' hack where existance of the file triggers the safe mode? This way mmwrapper doesn't have to know about it at all (this 'recovery mode' could still be useful, but isn't tied to the minimenu change). I'll try to whip something up (though it might take a while).

 

[Trip]

I can get it to loop every time by first making all the folders into tabs. This messes up after a while and only shows one tab.

Then it's just a case of ejecting the SD card and as the default tabs can't be shown it spazies out (technical term) until you put the card back in.

Let me know if you need someone to bug test Skeezix.

I'll try this later on when I get more time _jr_ cheers

 

[fusion_power]

MiniMenu should have more "failsave" mechanisms, it can crash to easily, especialy when you are not that familiar with it.  Examples are: not supported but still available themes and skins, remember last used app function, but when this app is already deleted or just disabled from showing in the menu ->crash.  And stuff like this. MiniMenu is nice but still needs some more attention to make it more userfriendly and save.

 

[_jr_]

I am also disappointed that the 'remember app' feature isn't stable. But I'm not into skinning. How about: I fix the remember crash this week, you fix a skinning crash?

edit: fixed the remember app feature; updated the first post with a test version (also including the git format patches)

edit: fixed two more crashes in corner cases and added a libpnd patch that adds subapp number recovery from desktop files

 

[_jr_]

Shamelessly bumping my own thread


Since some people seem to still be using minimenu I was motivated enough to fix two minor bugs I noticed recently. The attachment in the first post has been updated.


@skeezix: included is also a patch to libpnd recovering subapp number from desktop file name (which fixes minimenu based ovr editing when using desktop files)