The scan results are still stuck "Importing"
1. System->Configuration License shows a valid license. IP limit 34 active of 10000. License expires Feb 2018. (No problem here)
2. There is a possible error near the subject scan. It never shows before the specific scan, but continues on well after the scan.
I have System->System Logs show the following regarding the Wake-on-LAN scan #19320 occuring between 19:17 and 19:30:
19:17 Scan job #19320 Starting...
19:17 Scan job #19320 (Wakeup RDTENetwork - #6) has acquired Scan "Wakeup RDTENetwork"
19:28 DATABASE ERROR: SQLSTATE[HY000]: General Error: 5 database is locked
19:28 jobd has failed to get the job list. It will continue to try for 60 minutes before shutting down.
19:30 jobd has been able to get the job list after 2 minutes.
19:30 Plugin Update job #19334 has started.
19:30 Scan job #19320 (Wakeup RDTENetwork - #6) (Wakeup RDTENetwork) has ended.
19:31 DATABASE ERROR: SQLSTATE[HY000]: General Error: 5 database is locked
19:32 DATABASE ERROR: SQLSTATE[HY000]: General Error: 5 database is locked
19:32 jobd has failed to get the job list. It will continue to try for 60 minutes before shutting down.
19:34 DATABASE ERROR: SQLSTATE[HY000]: General Error: 5 database is locked
19:34 jobd has been able to get the job list after 2 minutes.
19:36 DATABASE ERROR: SQLSTATE[HY000]: General Error: 5 database is locked
Suggestions to remove the stuck scan???
All help appreciated!
>OK, try to restart Security Center process or the full machine, it should unlock the database.
Restarted the entire RHEL server (and SC). Following reboot, the logs confirm prior to reboot "SIGTERM sent to jobd"" and after reboot "Jobd starting...". Logs are quiet and there are no entries other than successful login entries. (No errors)
..and to be clear, there have been no database locks over the past two days. Database locks only occurred for a brief period which coincides with the stuck scan result.
Is there no way to clear the stuck "Importing" scan result?
Database lock issues are often caused by a job queue that is to long, and all restarting does, is make the processes restart. While restarting will make it easier to troubleshoot, there are things you need to know to look at the data correctly. If you are having this many database locks you need to call Technical Support and work with them over the webex to fix the issue.
Upon further examination using sqlite3 and examining the file system under /opt/sc/ I found that:
1. In the folder /opt/sc/ there are several databases. Using sqlite3 .tables, .schema and .dump commands, I examined the contents of the jobqueue.db. That database has nothing but current active jobs in the 21000 range. No mention of past job #19320 which is the job ID which resulted in a stuck "Importing" scan report.
I also examined the application.db tables, schema, and data with the sqlite3 command. Likewise, there seem to be no table or data values supporting past job #19320. Good indications that after a scan completes, it's no longer in the sc database.
2. Navigating to /opt/sc/data/scans/ I noticed there are a bunch of folder names with past job numbers that correspond to completed scan jobs. This INCLUDES folder name /19320/ ..which is the ID of the stuck scan report. I also noticed that within each numeric folder there is also a database file called progress.db file in each of the folders. Again, sqlite3 reveals tweakable data fields that can change or fix this report's metadata.
Anyone know if I can safely delete /opt/sc/data/scans/19320/ ..or is there are database somewhere that will loose a reference to the 19320 folder name? I can also tweak a value in the progress.db to indicate that it is a completed scan result. No other database table seems to account for the completed scan jobs other than the folders in the file system.
(Tech support call is not an option for me.)