TP needs daily re-boot

[GMMan]

luna-send -n 1 luna://com.palm.db/compact {}

[knightjorb]

Originally Posted by GMMan

luna-send -n 1 luna://com.palm.db/compact {}

I tried using that on my touchpad with wterm, but permission was denied.

Would I need to use a command line on a desktop computer?

[GMMan]

Originally Posted by knightjorb

I tried using that on my touchpad with wterm, but permission was denied.

Would I need to use a command line on a desktop computer?

You need to be root to run luna-send. Type:

su

[knightjorb]

I did that but it asked me for a password, what would that be?

[GMMan]

It would be whatever you've set the first time you started wTerm. If you didn't set one, try hitting Enter, though it may not accept that. If you need to set the password, look in wTerm's app menu for a setup option.

[va20171]

Originally Posted by GMMan

luna-send -n 1 luna://com.palm.db/compact {}

I run the command and saw the mojodb-luna process going to 90%, just like the issue at 1:00AM EST. I did not loose my accounts, but the mojodb process would just keep consuming CPU. I have not seen any relevant error in my logs (set to the webos default log level).

I have another touchpad for my son which has Android running. It has the App Catalog 5.0.3400 just like mine, so I will leave on webOs tonight and will check on the issue tomorrow. I am not so sure the latest App Catalog is the issue as this thread was open on february. I think App Catalog was updated a few months later. I will post my findings tomorrow.

[knightjorb]

I just tested using the compacting command in wterm, and I was able to replicate the problem each time, regardless of wether WiFi or backup were on. I also captured the logs just before I executed the command, and after.


undefined[2012-12-22 06:13:15] (kernel) kern.info: [ 283.310021] gpio-keys: core navi button pressed
[2012-12-22 06:13:15] (kernel) kern.info: [ 283.449993] gpio-keys: core navi button released
[2012-12-22 06:13:17] (kernel) kern.info: [ 286.092510] mdp_bus_scale_update_request: Setting bus scaling index 2
[2012-12-22 06:13:19] (mojodb-luna[1836]) user.notice: [db.mojodb] compacting...
[2012-12-22 06:13:20] (kernel) kern.info: [ 288.462557] cpufreq: cpu 1 is not active.
[2012-12-22 06:13:20] (mojodb-luna[1836]) user.warning: [db.bdb] Starting compact: Checkpoint freed 4186112 bytes. Volume /var/db has 203042816 bytes free out of 251625472 bytes (19.3 full)
[2012-12-22 06:13:20] (kernel) kern.info: [ 289.029994] gpio-keys: core navi button pressed
[2012-12-22 06:13:21] (kernel) kern.info: [ 289.209992] gpio-keys: core navi button released
[2012-12-22 06:13:21] (kernel) kern.info: [ 289.794865] mdp_bus_scale_update_request: Setting bus scaling index 1
[2012-12-22 06:13:29] (kernel) kern.info: [ 297.692889] cpufreq: cpu 1 is not active.
[2012-12-22 06:13:31] (kernel) kern.notice: [ 299.532460] msm_timer_set_next_event(12) clock dg_timer, alarm already expired, now 5ca8e290, alarm 5ca8e299, late -9
[2012-12-22 06:13:32] (kernel) kern.info: [ 300.185092] IPT_PACKET_DROPPED_NO_MATCH: IN=eth0 OUT= MAC=00:1d:fe:e9:05:d8:00:26:f2:96:cd:97:08:00:45:00:00:4e:b3:1a:40:00:40:11:03:f7:c0:a8:01:01:c0:a8: 01:3c:08:00:00:89:00:3a:81:fe:b3:1b:00:10:00:01:00:00:00:00:00:00:20:43:4b:41:41:41:41:41 SRC=192.168.1.1 DST=192.168.1.60 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=45850 DF PROTO=UDP SPT=2048 DPT=137 LEN=58
[2012-12-22 06:13:33] (kernel) kern.info: [ 301.369982] gpio-keys: core navi button pressed
[2012-12-22 06:13:33] (kernel) kern.info: [ 301.540019] gpio-keys: core navi button released
[2012-12-22 06:13:35] (kernel) kern.info: [ 303.222623] cpufreq: cpu 1 is not active.
[2012-12-22 06:13:50] (failed) pthread loc.: Resource deadlock avoided
[2012-12-22 06:13:50] (mojodb-luna[1836]) user.err: [db.bdb] bdb: PANIC: Resource deadlock avoided
[2012-12-22 06:13:50] (mojodb-luna[1836]) user.err: [db.bdb] bdb: PANIC: fatal region error detected; run recovery
[2012-12-22 06:13:50] (DB_RUNRECOVERY) DB_TXN->abort: log undo failed for LSN: 812 198016.: Fatal error, run database recovery
[2012-12-22 06:13:50] (DB_RUNRECOVERY) PANIC.: Fatal error, run database recovery
[2012-12-22 06:13:53] (kernel) kern.info: [ 321.680042] gpio-keys: core navi button pressed
[2012-12-22 06:13:53] (kernel) kern.info: [ 321.870018] gpio-keys: core navi button released
[2012-12-22 06:13:58] (kernel) kern.info: [ 326.451047] cpufreq: cpu 1 is not active.

hopefully some of you can make sense of it.

[GMMan]

[2012-12-22 06:13:50] (failed) pthread loc.: Resource deadlock avoided 
[2012-12-22 06:13:50] (mojodb-luna[1836]) user.err: [db.bdb] bdb: PANIC: Resource deadlock avoided 
[2012-12-22 06:13:50] (mojodb-luna[1836]) user.err: [db.bdb] bdb: PANIC: fatal region error detected; run recovery 
[2012-12-22 06:13:50] (DB_RUNRECOVERY) DB_TXN->abort: log undo failed for LSN: 812 198016.: Fatal error, run database recovery 
[2012-12-22 06:13:50] (DB_RUNRECOVERY) PANIC.: Fatal error, run database recovery

This is what I saw last time before I compiled db_recover. Maybe there's something systematically wrong with the way MojoDB's going at it. Maybe a temporary workaround would be to unschedule old entry purging and see if it would stop compacting the database. (Interesting to note: old entry purging is done every 5 minutes, while compacting is done perhaps daily.)

[jr92811]

Originally Posted by GMMan

When I ran the manual compact it seems it never ended, and used 99.4% CPU, so that's why I'd expect a power drain.

Can more people confirm that they had the problem after something failed with App Catalog?

There are 2 Touchpads in the house, both running the latest version of Apps Catalog. One TP has no obvious problems, the other suffers the 'daily re-boot' issue. On this TP I had installed Pivot, and when the App Catalog was fired up I never reached a front page. There was a message saying it was 'working hard'. Yet I could still jump to the various tabs. Yesterday I deleted the Catalog and Pivot patch. I now have a standard front page, but it didn't fix the 'daily re-boot'.

Hope this helps. I use the Reboot Scheduler for about 4am every morning.

[ChLange]

Since a few weeks, I do also have this problem. I have to reboot my TP nearly every day. When it does this "lockup", no list is loaded anymore. Be it music player, video player or even the email-app.
Sometimes, it is mojodb-luna, which is using more than 90% of the cpu, but sometimes, I don'teven see this process in "top" (using wterm) and WebAppMgr is using nearly 20% cpu and 30% RAM.
Strikingly often, it occurs when I had the music-player app run for a long time. I will test if this doesn't occur when I'm not using the music player.

[knightjorb]

So do we have a solution yet?

[ChLange]

Happens even when l'm not using any media-related service (like playing music).

Additional note: The browser displays a popup reading "no internet connection" on every site I surf to but loads it normally. As if a part of webos think that there is no internet connection, but the other part uses it normally.

[shanpalm61]

GMMan, how's the progress coming along with this problem?

[tstraetker]

My tp also has this problem - since July 2012.

Info in case it could help:

It is almost stock - out of the box. No preware, no doctoring, no attempt at android, minimal apps. Just basic use - email and web.

The only change was a day 1 suggestion that I followed to "minimize data collection." I never messed with the clock speed or any other things also being talked about at that time - firesale Aug 2011. Otherwise, I did upgrade to webos 3.0.5 in Oct-ish 2011?

The only odd thing, somewhat coincident with the start of the problem, I once hit a size/partition limit(?) on photo downloads - some 150ish photos at 770k-ish each? Could an over run of such a partition screw up the data in the next partition?

I reboot every morning. If I don't reboot, because it seems ok, the problem just seems to appear an hour or so later anyway.

[GMMan]

I haven't been working on the TouchPad too much over the holidays, but I'll get a start again.

Originally Posted by tstraetker

I reboot every morning. If I don't reboot, because it seems ok, the problem just seems to appear an hour or so later anyway.

Wow, that frequent?

[va20171]

Originally Posted by GMMan

I haven't been working on the TouchPad too much over the holidays, but I'll get a start again.



Wow, that frequent?

I think what he meant is that in the morning, if the TP did not loose the accounts and he does not reboot TP, it will probably loose the accounts within an hour. After I overclocked my touchpad, the occurrences of account lost have been reduced, however mojodb stays 'running' at 90% CPU right after 1:05 AM EST.

Last week, I left my son's TP in webOs overnight, but I have not seen the problem. His TP has android and we rarely boot in webOs account (there is no other account setup in webOs, except for the webOs account). It could be that we need to keep using webOs continuously or something else triggers the issue. The HP App Catalog version is the same as my TP.

[tstraetker]

Yes, it is easier to just do the 'restart' first thing. Recently, the accts look fine upon an AM wakeup - WiFi off all night. I restart anyway, because the several times that I didn't, I had to restart an hour later.

WiFi is off all night, but backup is turned on - any conflicts? I could manually turn off backups last thing, then on in the am.
Location Services are almost always - Don't Allow.

I just moved all photos to my pc, and deleted all of my downloaded files off of the USB drive. (A little reluctant to do any of the four 'erase' options listed under Device Info - unnecessarily?)

I ran an external device Avast security scan from my pc - no issues found. Could this problem still be a trojan or a virus type issue? It came suddenly and hasn't gone away.

This tp is now close to stock, with minimal user data on it. Over the weekend, I'll monitor more exactly when the problem occurs.

[GMMan]

The 90% CPU issue matches the description of earlier test results from the TouchPad clone I got half a month ago. It's caused by database compacting. I'll see if I can figure out how to disable the automatic purging activity.

[Loiter]

I have the problem for about a month (or a bit more).
The browser doesn't load any bookmarks (although manually typing urls works), Facebook cannot connect, mails not loading etc.
To be honest I don't use the TP that much so I haven't made any changes recently that could be the culprit.
The App Catalog could be to blame. When the problem exists I cannot manually backup (or see when it was the last time I backed up)
It's a bit frustrating to be honest.
GMMan has been very nice to try to help, I hope there is a solution.

[GMMan]

Checked Activity Manager, and there's an entry that seems to fit the bill. An activity for com.palm.db named mojodbpurge has an interval of 1d, and I'm sure immediately after purging old entries the DB wants to compact, then become unresponsive during the compact.

If you have Impostah you may want to check the time listed when the activity last finished and see if it matches the time your DB stops working.
Impostah->Activities->Service Persistent/db : mojodbpurge->Show->schedule->lastFinished