Merry Christmas hydrusdev.

>>11099 merry xmas

>>11100 shill

>>11101 merry christmas

>>11100 who dat?

>>11103 a shill

>>11105 >>11106 >>11107 speaking of shills…

>>11108 fuck off josh

>>11109 wew

>>11110 we have IDs here cowshitter

>>10944 Finally this happened again. Hydrus had to run a pretty big maintenance job at exit, and once it was done it's just stuck there in the task manager as client.exe. I noticed about two and a half hours after I exited the program. There are no .db-shm and .db-wal siblings in the db folder, and it's not using CPU/HDD. However, once I started writing this, it actually did shut down. Since I only caught this just before it shut down my notes about the .db file siblings and CPU/HDD usage might not be accurate. Here's the log, notice the 2 hour gap…
2018/12/26 09:15:06: hydrus client started
2018/12/26 09:15:06: booting controller…
2018/12/26 09:15:06: booting db…
2018/12/26 09:15:06: preparing disk cache
2018/12/26 09:15:10: preparing db caches
2018/12/26 09:15:10: booting db…
2018/12/26 09:15:10: initialising managers
2018/12/26 09:15:17: booting gui…
2018/12/26 09:15:21: Import folder cosplay imported 6 files.
2018/12/26 09:18:51: shutting down gui…
2018/12/26 09:18:51: waiting for daemons to exit
2018/12/26 09:18:53: vacuuming main
2018/12/26 09:18:53: Vacuumed Y:\db\client.db in 176 milliseconds
2018/12/26 09:18:53: Could not vacuum Y:\db\client.mappings.db (probably due to limited disk space on db or system drive).
2018/12/26 09:18:53: vacuuming external_master
2018/12/26 09:20:04: Vacuumed Y:\db\client.master.db in 1 minute 10 seconds
2018/12/26 09:20:04: vacuuming external_caches
2018/12/26 09:20:06: Vacuumed Y:\db\client.caches.db in 2.2 seconds
2018/12/26 09:20:06: database maintenance - analyzing

done!
2018/12/26 09:20:06: public tag repository sync: processing updates
2018/12/26 09:20:06: analyzing specific_deleted_mappings_cache_1_3
2018/12/26 09:20:06: analyzing specific_deleted_mappings_cache_9_3
2018/12/26 09:20:06: analyzing deleted_mappings_3
2018/12/26 09:20:06: fattening service info
2018/12/26 09:21:07: processed 1172848 definitions at 21831 rows/s
2018/12/26 09:30:02: processed 7445542 content rows at 13909 rows/s
2018/12/26 09:30:47: shutting down db…
2018/12/26 09:30:48: cleaning up…
2018/12/26 09:30:48:
2018/12/26 12:08:51: shutting down controller…
2018/12/26 12:08:51: hydrus client shut down


>>11098 Merry Christmas and thanks for a great year with Hydrus!

>>11098 Merry christmas.

>>11113 Thank you for this follow-up. Since the db does seem fully shut down and disconnected, my best guess here is that one of the daemon threads (which do maintenance stuff in the background) isn't waking up to receive the 'program shutdown' signal properly. In this case, the process will hang on, with that one thread asleep, until it wakes according to its natural check period (which are typically on the order of hours). I will check this code. It may also magically fix in py3 due to the different way some thread signalling works as well, so please let me know if this improves/worsens after v335. In this case, as the db is completely closed, there is no danger in just killing the process in task manager when this happens again.