Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #4011

Closed (moved)
Open
Opened Sep 13, 2011 by Roger Dingledine@arma

0.2.3.3 relay won't fetch microdesc consensus on startup if it already has a normal consensus

In networkstatus.c we have:

/** A time before which we shouldn't try to replace the current consensus:
 * this will be at some point after the next consensus becomes valid, but
 * before the current consensus becomes invalid. */
static time_t time_to_download_next_consensus = 0;

which we use in update_consensus_networkstatus_downloads() to decide whether to break out:

  if (time_to_download_next_consensus > now)
    return; /* Wait until the current consensus is older. */

The result is that we don't even try to fetch a microdesc consensus if the ns consensus we have is recent enough.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Tor: 0.2.3.x-final
Milestone
Tor: 0.2.3.x-final
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#4011