Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #2570

Closed (moved)
(moved)
Open
Created Feb 15, 2011 by Karsten Loesing@karsten

Try harder to detect when Tonga's bridge snapshots are stale

When sanitizing bridge snapshots from Tonga, we make sure that the tarballs are not older than a couple of hours. If they are, we log a warning, so that we know early when Tonga is broken.

We overlooked the case when Tor crashes on Tonga, but the cronjob creates new tarballs with stale content every 30 minutes. We did not detect this, because we have to infer the status publication time from the tarball name (there is no publication time in bridge network statuses). This is how we did not detect that Tonga was broken for two weeks.

We should check the descriptor publication times for plausibility. If a status does not have a descriptor published in the last, say, 3 hours before the status was published, there's probably something wrong. We should print out a warning in this case, too, and investigate the problem.

We might also look at the last-modified times of files contained in the tarballs. In theory, the time difference between writing these files and writing the tarball should not be higher than 1 hour.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking