[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #13125 [Tor]: Review the guardiness python script of #9321
#13125: Review the guardiness python script of #9321
------------------------+--------------------------------
Reporter: asn | Owner:
Type: defect | Status: needs_review
Priority: normal | Milestone: Tor: 0.2.7.x-final
Component: Tor | Version:
Resolution: | Keywords: tor-guard tor-auth
Actual Points: | Parent ID: #9321
Points: |
------------------------+--------------------------------
Comment (by asn):
Replying to [comment:9 Sebastian]:
> Looks plausible, I could see myself trying it out. A couple of things:
The cron script should never output a single thing in the case where no
errors happened, but if an error happened it should always make sure that
gets reported.
Fixed that I think. Now it should be totally silent if everythin went
well, but still cry if things went bad. I'm testing this right now on my
system.
> There probably wants to be a vacuum somewhere so the database file gets
shrunk periodically.
I didn't do this yet.
> There should be a protection against parallel execution of the script,
because that will happen eventually.
Fixed with flock(1).
> What is the deal with not importing a consensus if it isn't valid
anymore? I don't understand the logic. The duplicate protection should
prevent duplicates, so what's the issue?
You are right. Now the date check happens only on guardfraction.py. The
databaser script will just import whatever is found in the directory it
was pointed to.
> For the output format, I thought we had talked about giving a way to
enumerate which consensuses were missing. Maybe that could at least be an
optional command?
Did this. It's now switch `-m` in guardfraction.py . Check it out!
>Also, instead of
> {{{
> n-inputs <number of consesuses parsed> <number of months considered>
> }}}
>
> maybe
>
> {{{
> n-inputs <number of consensuses parsed> <number of all consensuses in
voting period> <number of months considered>
> }}}
>
> is more appropriate/easier to understand? Because otherwise "how many
hours is a month" becomes an issue.
>
As discussed in IRC, I changed the period to be in days and not in months.
This is much better. And I also output the ideal number of consensuses in
the output file.
> What happens with consensuses generated at the half-hour mark? Can they
accidentally get added, and if they do, do they distort results?
I think they can get added but they don't really distort results.
They will definitely not be considered by the `list missing consensuses`
functionality.
Please check the new changes out!
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13125#comment:10>
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