Might there be some way of preventing indexing Sunday mornings or switching the time ran from 2am to 1 or 3am? It looks like solr indexing is behind this issue and this is the second DST switch that I've had to go into the db and switch a time entry manually.
I don't know much about solr or how it gets scheduled with an ASpace internal solr instance. I was looking at some of the solr docs and it looks like there is an xml file for some solr settings but I wasn't able to locate one within ASpace's file structure. -Alan Huebschen University of Illinois at Springfield Brookens Library Information Systems ________________________________ From: [email protected] <[email protected]> on behalf of Blake Carver <[email protected]> Sent: Monday, March 9, 2020 1:48 PM To: Archivesspace Users Group Subject: [EXTERNAL] Re: [Archivesspace_Users_Group] update of previous post archivesspace 'manage user access' pages give error It's probably a problem brought on by the change of time this week. Try this: MySQL [archivesspace]> select * from auth_db; +------+------------------+---------------------+---------------------+--------------------------------------------------------------+ | id | username | create_time | system_mtime | pwhash | +------+------------------+---------------------+---------------------+--------------------------------------------------------------+ | 1 | admin | 2016-03-09 07:10:13 | 2016-03-09 07:10:13 | $2a$10$Gp0oqAuyVXmG/M1s7XDcTuz8.6aTRooPxbf.AWNUuhxNvzsjTa7om | | 2 | search_indexer | 2016-03-09 07:10:14 | 2019-10-05 08:33:40 | $2a$10$WEoh7JjTOFZ.m.ih9sbxPOHomfcReIBlnAoRQceAbwWFK0DuyC8Tm | Take a look atsearch_indexer and the 2 times. The system_time is probably the one with the bad hour. You can just update that the current time and that should do it. So something like update auth_db set system_mtime = NOW()where username = search_indexer. ________________________________ From: [email protected] <[email protected]> on behalf of Daniel Sprouse <[email protected]> Sent: Monday, March 9, 2020 2:35 PM To: Archivesspace Users Group <[email protected]> Subject: [Archivesspace_Users_Group] update of previous post archivesspace 'manage user access' pages give error new information added, and new log files attached. I am homing in on the issue here, thinking it is a java version issue, or a java version recognition issue. If anyone has seen anything like this, any guidance would be appreciated. after migrating from 2.7.0 to 2.7.1, and from mysqld Ver 5.7.16 to mysqld Ver 8.0.16, from java 1.7 to 1.8 [root@tslac4avwebtest archivesspace]# java -version openjdk version "1.8.0_232" OpenJDK Runtime Environment (build 1.8.0_232-b09) OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode) BUT... when it was working, the output on the backend webpage showed java 1.7! (I think that not seeing java 1.8 is probably the issue) backend_url http://aristest.tsl.texas.gov:8089 { "databaseProductName": "MySQL", "databaseProductVersion": "8.0.16", "ruby_version": "2.3.0", "host_os": "linux", "host_cpu": "x86_64", "build": "java1.7", "archivesSpaceVersion": "v2.7.1" } ------------------------------------- Archivesspace started normally several times on Friday, but I got errors when I went to user management pages. archivesspace admin account 'System'->'manage users' and 'Repository Settings'->'manage user access' pages give error http://arisint.tsl.texas.gov:8080/users http://arisint.tsl.texas.gov:8080/users/manage_access "We're sorry, but something went wrong." I have not found any other pages that give this error. attached is a tail -f of archivesspace.out while attempting to get to 'System'->'manage users' and a diagnostic spawned by archivesspace, aspace_diagnostic_1583775751.txt [cid:f31f7ef0-8e07-4602-9acc-c50afd47b573]
_______________________________________________ Archivesspace_Users_Group mailing list [email protected] http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
