Bug #6875
Production CN continues to harvest from LTER Metacat MN even when sync=false and state=down
100%
Description
In preparation for transition from Metacat to GMN as the default LTER MN, node registration was set to sync=false on 3 March to prevent any new content from being synchronized to the CN. On a date after 3 March, it was observed that content synchronization continued so the node registration was set to state=down. On 9 March, it was observed that the list object call continues to query Metacat (see below) and the latest harvest date is 6 March (also see below).
128.111.54.80 - - [09/Mar/2015:16:12:10 -0600] "GET /knb/d1/mn/v1/object?fromDate=2015-03-06T18:02:39.746%2B00:00&toDate=2015-03-09T22:12:00.004%2B00:00&start=0&count=1000 HTTP/1.1" 200 5150 "-" "Apache-HttpClient/4.2.6 (java 1.5)"
2015-03-06T18:02:39.745+00:00
Querying systemmetadata in Metacat on cn-ucsb-1.dataone.org for suspect objects results in the following list of objects that should not have been synchronized:
guid | date_uploaded | date_modified | authoritive_member_node
---------------------+---------------------+-------------------------+----------
knb-lter-hfr.239.1 | 2015-03-05 00:00:00 | 2015-03-05 06:09:12.292 | urn:node:LTER
knb-lter-hfr.241.1 | 2015-03-05 00:00:00 | 2015-03-05 06:09:12.974 | urn:node:LTER
knb-lter-hfr.242.1 | 2015-03-05 00:00:00 | 2015-03-05 06:09:13.662 | urn:node:LTER
knb-lter-hfr.240.1 | 2015-03-05 00:00:00 | 2015-03-05 06:09:12.5 | urn:node:LTER
knb-lter-hfr.243.1 | 2015-03-05 00:00:00 | 2015-03-05 06:09:14.749 | urn:node:LTER
knb-lter-gce.480.5 | 2015-03-03 00:00:00 | 2015-03-03 21:12:30.336 | urn:node:LTER
knb-lter-gce.481.7 | 2015-03-03 00:00:00 | 2015-03-03 21:12:30.776 | urn:node:LTER
History
#1 Updated by Robert Waltz about 9 years ago
How were the changes made to the node registration? Was there a call from LTER MN to updateNodeCapabilities on the CN?
#2 Updated by Mark Servilla about 9 years ago
Robert Waltz wrote:
How were the changes made to the node registration? Was there a call from LTER MN to updateNodeCapabilities on the CN?
Initially, through Metacat, which failed to set sync correctly; lastly, using Apache Directory Studio to set both sync and state attributes.
#3 Updated by Robert Waltz about 9 years ago
If Apache Studio is used to alter attributes in LDAP, then the processing daemon will need to be restarted.
#4 Updated by Robert Waltz about 9 years ago
Since updateNodeCapabilities appears to have failed on the CN, and an administrator changed the ldap properties directly, then d1-processing should be recycled to pick up the new attributes.
(11:52:42 AM) waltz: 1. Send email to Ops regarding the restart
(11:53:18 AM) waltz: vi /etc/dataone/process/logAggregation.properties
(11:53:44 AM) waltz: change logAggregator.active=TRUE to FALSE
(11:55:11 AM) waltz: 3, change /etc/dataone/process/synchronization.properties setting Synchronization.active=TRUE to FALSE
(11:56:31 AM) waltz: 4. change /etc/dataone/process/replication.properties setting Replication.active=TRUE to FALSE
(11:57:29 AM) waltz: 5. confirm that logAgg, Synch and replication are reporting being down.
(11:57:33 AM) waltz: > tail -30f /var/log/dataone/synchronize/cn-synchronization.log
(11:58:48 AM) waltz: > tail -30f /var/log/dataone/logAggregate/cn-aggregation.log
(12:00:50 PM) waltz: 6. /etc/init.d/d1-processing stop
(12:01:29 PM) waltz: 7. make certain it really stopped
(12:02:21 PM) waltz: > ps gauxwww | grep 'java' look for d1_processing_daemon
(12:03:28 PM) waltz: 8. /etc/init.d/d1-processing start
(12:03:37 PM) waltz: oops
(12:03:43 PM) waltz: scratch 8
(12:03:48 PM) marco: :-)
(12:05:02 PM) waltz: 8. change logAggregation.properties, synchronization.properties and replication.properties back to 'TRUE'
(12:08:52 PM) waltz: 9. /etc/init.d/d1-processing start
#5 Updated by Robert Waltz over 8 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
