[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #16401 [Onionoo]: Fail-fast if file access permissions for out and status prevent an update

#16401: Fail-fast if file access permissions for out and status prevent an update
-----------------------------+-----------------
     Reporter:  leeroy       |      Owner:
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:
    Component:  Onionoo      |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+-----------------

Comment (by leeroy):

 Okay, while working on this I read the logback documentation. In
 particular to see if there is support for rate-limiting-like feature. I
 found the following options for candidate tickets (improvements to
 logging).

  1. Use a
 [http://logback.qos.ch/manual/filters.html#DuplicateMessageFilter
 DuplicateMessageFilter]. Not really rate-limiting, but an alternative. It
 drops duplicate messages after a threshold.


  1. Implement an
 [http://logback.qos.ch/manual/appenders.html#WriteYourOwnAppender
 Appender]. This provides control over the events which make it through to
 the Encoder. By going with this option it would be possible to replace a
 flood with a message about n-similar messages in past m-seconds.



 Neither option would stop the updater from running despite permission
 problems. So I checked the source and it seems like it would be cumbersome
 to implement this in the classes that depend on out, status, in. The
 easiest way would be to just check as needed prior to instantiating them
 in the updater's Main class. I created some static members which I've
 placed in LockFile.checkAccessWithPath(String). Maybe not the best place,
 but the updater loads that class anyway. Let me know if you prefer
 something else. Otherwise I'll test a patch for the updater and lockfile
 with better permission handling.

 I'll wait for the updater to go through some normalization, and for more
 improvement to bulk imports before the backup/restore.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16401#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs