Sysmon problem

After restoring both HDRs from the crash discussed in a separate thread, all has returned to normality with one exception. Sysmon on one of the boxes doesn't display its graphs. It isn't a browser issue, since I've tried on other browsers, including a virgin uncustomised version of the latest Firefox to no effect. In any case, it works fine on the other similarly configured box.

Someone suggested deleting /mod/monitor/monitor.db in case it was corrupted. I tried that again to no effect. But looking at the file after every try after every subsequent running of Sysmon shows it to be growing and having the curent date and time. I examined the file in a database viewer and the figure for temperature and smart output agreed with results from other checks. So it seems that can write to the file, but for some reason cannot read it.

Any ideas?
 
Does the package list show webif-charts as being installed?

In the broken-webif thread @4ndy also had problems with the charts package which would explain difficulties with displaying sysmon output

You could also look at webif-error.log to see if there are any relevant error messages
 
Does the package list show webif-charts as being installed?

In the broken-webif thread @4ndy also had problems with the charts package which would explain difficulties with displaying sysmon output

You could also look at webif-error.log to see if there are any relevant error messages


Thanks for the tip. It was installed, but I guessed that like some other packages after the crash, it needed to be uninstalled then reinstalled. I couldn't do it from the packages menu because the webif itself is a dependent. After a bit of trial and error, running "Humax2# opkg install webif-charts --force-reinstall" succeeded and Sysmon is now working as advertised.
 
An easier option might have been to delete the /mod/monitor/monitor.db file, within which a corruption could have stopping it working.

There is a history of the various SQLite .db files getting corrupted and breaking something; deleting (or renaming, if you want to preserve the evidence) effectively clears the corruption and causes a fresh version to be saved (without any previous information retained of course).
 
An easier option might have been to delete the /mod/monitor/monitor.db file, within which a corruption could have stopping it working.

There is a history of the various SQLite .db files getting corrupted and breaking something; deleting (or renaming, if you want to preserve the evidence) effectively clears the corruption and causes a fresh version to be saved (without any previous information retained of course).
The OP had already done that without success, read post 1
 
The latest versions of Sqlite3 (3.32.3 currently) have a ".recover" command (but we're still on 3.27.2).
I don't know if this would fix the database, but it would be nice to try it.
I don't have any corrupt database samples though.
 
I’m having problem with sysmon.
It just sticks in loading.
The Webif log shows
Code:
16 at file "/mod/webif/plugin/sysmon/data/temp.jim", line 12
15 /mod/webif/plugin/sysmon/data/temp.jim:12: Error: database disk image is malformed
14 at file "/mod/webif/lib/setup", line 8
13 in procedure 'require' called at file "/mod/webif/lib/system.class", line 417
12 at file "/mod/webif/lib/setup", line 8
11 in procedure 'require' called at file "/mod/webif/lib/setup", line 13
10 at file "/mod/webif/cgi-bin/vfd.jim", line 3
9 /mod/webif/lib/setup:8: Error: couldn't read file "/mod/webif/lib/pretty_size": No such file or directory
8 at file "/mod/webif/plugin/sysmon/data/cpu.jim", line 10
7 /mod/webif/plugin/sysmon/data/cpu.jim:10: Error: database disk image is malformed
6 at file "/mod/webif/plugin/sysmon/data/temp.jim", line 12
5 /mod/webif/plugin/sysmon/data/temp.jim:12: Error: database disk image is malformed
4 at file "/mod/webif/plugin/sysmon/data/temp.jim", line 12
3 /mod/webif/plugin/sysmon/data/temp.jim:12: Error: database disk image is malformed
2 at file "/mod/webif/plugin/sysmon/data/temp.jim", line 12
1 /mod/webif/plugin/sysmon/data/temp.jim:12: Error: database disk image is malformed

Please can you advise how to “repair” the system/db.


Sent from my iPad using Tapatalk
 
Thanks Mymsman.
I ran prpr’s command from the indicated thread.
Code:
cd /mod/monitor && sqlite3 monitor.db ".clone temp.db" && mv temp.db monitor.db

It seems to have fixed the db. And SysMon is running fine now.

Not sure how to run the .recover option. I’m not a unix or sql expert.


Sent from my iPad using Tapatalk
 
Or if you have samba access to your humax disk you could try the .recover command that @prpr mentions above
Even though I'm running sqlite3 3.36.0 (as opposed to the release version 3.27.2), the ".recover" command doesn't work on the Humax (error is "SQL error: no such table: sqlite_dbpage").
I've never been sufficiently interested/had enough circular tuits thus far to see if I can work out why. The internals of sqlite are not somewhere I particularly wish to go.
 
Presumably it can only recover DBs made with a sufficiently recent sqlite version?
 
Transplant the database file on to a real Linux machine (with distribution release which is 3.31.1) and the command works, so it's not something in the file itself.
 
So is it absolutely certain that the 3.36 version library is being used, rather than some other version hanging about? Or is there some build option that should have been set?
 
So is it absolutely certain that the 3.36 version library is being used, rather than some other version hanging about?
I would say it is:
Code:
humax ~ # env|grep LD_LIBRARY_PATH
LD_LIBRARY_PATH=/mod/lib:/lib:/usr/lib
humax ~ # sqlite3 
SQLite version 3.36.0 2021-06-18 18:36:39
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .q
humax ~ # LD_LIBRARY_PATH=/usr/lib:/lib:/mod/lib sqlite3
SQLite header and source version mismatch
2011-01-28 17:03:50 ed759d5a9edb3bba5f48f243df47be29e3fe8cd7
2021-06-18 18:36:39 5c9a6c06871cb9fe42814af9c039eb6da5427a6ec28f187af7ebfb62eafa66e5
Or is there some build option that should have been set?
After a bit of research it seems so - SQLITE_ENABLE_DBPAGE_VTAB - and now it works.
 
Back
Top