[tor-bugs] #19720 [Metrics/CollecTor]: CollecTor should be re-configurable without restart

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Aug 8 10:10:10 UTC 2016


#19720: CollecTor should be re-configurable without restart
-------------------------------+---------------------------------
 Reporter:  iwakeh             |          Owner:  iwakeh
     Type:  enhancement        |         Status:  needs_review
 Priority:  High               |      Milestone:  CollecTor 1.0.0
Component:  Metrics/CollecTor  |        Version:
 Severity:  Normal             |     Resolution:
 Keywords:  ctip               |  Actual Points:
Parent ID:                     |         Points:
 Reviewer:                     |        Sponsor:
-------------------------------+---------------------------------

Comment (by iwakeh):

 First some inline answers and then a summary below.

 Replying to [comment:8 karsten]:
 > Okay, I agree with most design decisions here, except for one that might
 confuse operators more than necessary: the modified time of the
 configuration file should not be checked once per minute (or even more
 often) but rather at the start of a new module run.  Imagine a situation
 where the next execution is less than 1 minute away and the operator makes
 a quick change to the configuration file.  There's no way for them to find
 out whether that change will make it into the next run or not, because the
 thread might check in 1 second or in 59 seconds.

 The Operator can answer this question from the log:

 Edit collector.properties and save.  The next check runs and reports the
 change:
 {{{
 2016-08-08 09:15:56,948 INFO o.t.c.c.Configuration:63 Configuration file
 was changed.
 }}}

 Modules starting after that will receive the new configuration, which is
 explicitly reported.
 {{{
 2016-08-08 09:16:57,026 INFO o.t.c.c.CollecTorMain:45 Module updateindex
 received new configuration.
 2016-08-08 09:16:57,027 INFO o.t.c.c.CollecTorMain:53 Starting updateindex
 module of CollecTor.
 }}}

 Of course, at the moment there is a possible waiting time of 60sec. See
 summary below.


 > Can we change that by taking out the thread and having modules check
 whether the configuration has changed?

 The modified config file would be read by each module. A potential error
 will be noticed very late and all modules would have to deal with it. And,
 all modules now have to keep track of when the configuration changed.

 > Ideally, we'd have a shell script that we use to reload the
 configuration file and possibly to verify it without loading it.  But
 that's for later.
 >

 That would be two steps:
 1. Edit and save.
 2. Don't forget to inform the running application (not necessarily using a
 shell script, but it could be a wrapper for that).

 Step 2 is easily forgotten especially if there is a stressful situation
 requiring the change.


 === Summary
 Maybe the following changes will help:

 a) Keep the centralized modified-check.
 b) Decrease check interval < 5 sec (is this fine for the impatient?).
 c) Every module could also log that it received the notice about a config
 change (in the `update` method).  Currently it logs only that it received
 the changed configuration before the run that uses it.

 Using a) the config change can be detected centrally and a change will be
 effective when saved w/o additional steps for the operator.
 Part b) will make the application's response more immediate. Maybe even
 log the entire configuration file in TRACE level.
 Part c) also gives early feedback that the various modules will use the
 new configuration in their next run.

 In addition to the existing logging this should be sufficient feedback to
 the operator.
 Here an example of the planned log entries:

 Edit collector.properties and save; the resulting midified time of the
 properties file is 09:15:52.  The next check runs a few seconds later and
 reports the change:
 {{{
 2016-08-08 09:15:56,948 INFO o.t.c.c.Configuration:63 Configuration file
 was changed.
 2016-08-08 09:15:56,949 INFO o.t.c.c.Configuration:63 Module updateindex
 will use new configuration.
 2016-08-08 09:15:56,949 INFO o.t.c.c.Configuration:63 Module relaydescs
 will use new configuration.
 ...
 2016-08-08 09:16:57,026 INFO o.t.c.c.CollecTorMain:45 Module updateindex
 received new configuration.
 2016-08-08 09:16:57,027 INFO o.t.c.c.CollecTorMain:53 Starting updateindex
 module of CollecTor.
 ...
 2016-08-08 10:09:00,001 INFO o.t.c.c.CollecTorMain:45 Module relaydescs
 received new configuration.
 2016-08-08 10:09:00,002 INFO o.t.c.c.CollecTorMain:53 Starting relaydescs
 module of CollecTor.
 }}}


 What do you think?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19720#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list