Opened 11 months ago

Closed 11 months ago

Last modified 6 months ago

#28497 closed defect (fixed)

SBWS publishing badly broken vote documents

Reported by: starlight Owned by:
Priority: Medium Milestone: sbws: 1.0.x-final
Component: Core Tor/sbws Version: sbws: 1.0.2
Severity: Major Keywords:
Cc: pastly, juga Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

SBWS running as the longclaw bandwidth scanner began publishing vote documents with about 1600 descriptors on Saturday 11/17/18 at 15:00 UTC. Initially 1493 relay measurments were uploaded as reported here

https://lists.torproject.org/pipermail/tor-consensus-health/2018-November/009377.html

NOTICE: Bandwidth authorities have a substantially different number of measured entries: maatuska (6967), longclaw (1493), bastet (7042), gabelmoo (6949), moria1 (7084), Faravahar (7007)

the number of measurements declined each hour down to 1106 when this ticket was created during the hour following 11/18/18 05:00 UTC

the measurements uploaded appear to be stale values from several days ago, the last time SBWS was publishing from longclaw

Child Tickets

Change History (9)

comment:1 Changed 11 months ago by starlight

Summary: SBWS publising badly broken vote documentsSBWS publishing badly broken vote documents

comment:2 Changed 11 months ago by juga

After changing sbws to run from Debian package, the path were sbws was reading the raw measurements needed to be changed.
It should be fixed now.

comment:3 Changed 11 months ago by starlight

is #28500 the fix for this? would it not make more sense for the system to fail hard on a non-existent configuration file in order to force proper corrective action?

comment:4 in reply to:  3 Changed 11 months ago by juga

Replying to starlight:

is #28500 the fix for this?

yes, that's one part, the other other is in the Debian package https://salsa.debian.org/juxor-guest/sbws/commit/f294a98ef544014f64df14dd73bf4a4bb293daf2

would it not make more sense for the system to fail hard on a non-existent configuration file in order to force proper corrective action?

that's what i thought, but:

  1. in the Debian package is better to don't provide a default /etc/sbws/sbws.ini, so that it doesn't not get overwritten on updates if the operator modifies the file
  2. in the Debian package cron should call sbws with /etc/sbws/sbws.ini, but it won't exist by default and fail

i could add an environment variable to set the default user config and then the debian package could use it in the cron, instead of using the config file, but seemed simpler like this.

comment:5 Changed 11 months ago by starlight

ok, thank you for describing the complexity of the packaging

you can close this ticket if you think it's solve; I'm good with it

comment:6 Changed 11 months ago by juga

Resolution: fixed
Status: newclosed

ok, closing this this ticket because consensus-health says longclaw go back to 6000 relays aprox.
Feel free to open a new ticket if you realize it happens again.
Thanks for the report.

comment:7 Changed 7 months ago by juga

Correct version

comment:8 Changed 7 months ago by juga

Version: sbws: unspecifiedsbws: 1.0.2

Correct version

comment:9 Changed 6 months ago by teor

Milestone: sbws: 1.0.x-final

Moving closed sbws tickets to sbws: 1.0.x-final.

Note: See TracTickets for help on using tickets.