state-contents.txt 8.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242
  1. Contents of the Tor state file
  2. ==============================
  3. The state file is structured with more or less the same rules as torrc.
  4. Recognized fields are:
  5. TorVersion
  6. The version of Tor that wrote this file
  7. LastWritten
  8. Time when this state file was written.
  9. Given in ISO format (YYYY-MM-DD HH:MM:SS)
  10. MinutesSinceUserActivity (integer)
  11. Dormant (0, 1, or "auto")
  12. These values are used to keep track of how long Tor has been idle,
  13. for the purpose of becoming 'dormant' after a long period without
  14. any user-initiated requests.
  15. "MinutesSinceUserActivity" is the number of minutes since the last
  16. time the user asked us to do something. It is set to zero if we're
  17. dormant.
  18. "Dormant" is 1 if Tor was dormant when it wrote its state file, 0 if
  19. Tor was active, and "auto" if Tor was starting for the first time.
  20. AccountingBytesReadInInterval (memory unit)
  21. AccountingBytesWrittenInInterval (memory unit)
  22. AccountingExpectedUsage (memory unit)
  23. AccountingIntervalStart (ISO time)
  24. AccountingSecondsActive (time interval)
  25. AccountingSecondsToReachSoftLimit (time interval)
  26. AccountingSoftLimitHitAt (ISO time)
  27. AccountingBytesAtSoftLimit (memory unit)
  28. These fields describe the state of the accounting subsystem.
  29. The IntervalStart is the time at which the current accounting
  30. interval began. We were expecting to use ExpectedUsage over the
  31. course of the interval. BytesRead/BytesWritten are the total
  32. number of bytes transferred over the whole interval. If Tor has
  33. been active during the interval, then AccountingSecondsActive is
  34. the amount of time for which it has been active. We were expecting
  35. to hit the bandwidth soft limit in SecondsToReachSoftLimit after we
  36. became active. When we hit the soft limit, we record
  37. BytesAtSoftLimit. If we hit the soft limit already, we did so at
  38. SoftLimitHitAt.
  39. TransportProxy
  40. One or more of these may be present.
  41. The format is "transportname addr:port", to remember the address
  42. at which a pluggable transport was listening. Tor bridges use
  43. this information to spawn pluggable transport listeners in the
  44. same IP address and TCP port even after tor client restarts.
  45. BWHistory___Ends (ISO time)
  46. BWHistory___Interval (integer, number of seconds)
  47. BWHistory___Values (comma-separated list of integer)
  48. BWHistory___Maxima (comma-separated list of integer)
  49. These values record bandwidth history. The "Values" fields are a list,
  50. for some number of "Intervals", of the total amount read/written during
  51. that integer. The "Maxima" are the highest burst for each interval.
  52. Interval duration is set by the "Interval" field, in seconds. The
  53. "Ends" field is the ending time of the last interval in each list.
  54. Recognized values for "___" are:
  55. Read -- total bytes read
  56. Write -- total bytes written
  57. DirRead -- total bytes read for directory connections.
  58. DirWrite -- total bytes written for directory connections.
  59. IPv6Read -- total bytes read on IPv6 connections
  60. IPv6Write -- total bytes written on IPv6 connections
  61. LastRotatedOnionKey
  62. The last time that we changed our onion key for a new one.
  63. Given in ISO format (YYYY-MM-DD HH:MM:SS)
  64. This field is used to ensure that onion key rotations happen with the
  65. appropriate frequency.
  66. TotalBuildTimes
  67. CircuitBuildAbandonedCount
  68. CircuitBuildTimeBin
  69. These fields are used by the Circuit Build Timeout code, which
  70. tries to learn what times are reasonable for circuit construction,
  71. so that it can reject circuits that take too long to build.
  72. CircuitBuildTimeBin is a count of circuits that were build
  73. successfully in some timeframe. This entry can repeat; each of
  74. these represents some bar on a histogram. The first integer is a
  75. number of milliseconds; it tells the position of the center of the
  76. histogram bin on the time axis. The second number is a count of
  77. circuits in that bin.
  78. CircuitBuildTimeAbandonedCount is a count of circuits that we
  79. simply gave up on building because they were taking far too long.
  80. TotalBuildTimes is the number of circuit build times that we
  81. observed in order to build the above measurements fields. If it
  82. reaches a cap, then older measurements get thrown away.
  83. Guard [key=value] [key=value]...
  84. Describes a single entry guard used by the client. Key=value
  85. entries with unrecognized keys are persisted. Order is not
  86. significant. For more information about terminology used here,
  87. system, see guard-spec.txt in the tor specifications repository.
  88. Recognized keys are:
  89. in (string)
  90. The name of a guard selection that this guard is in.
  91. rsa_id (string)
  92. RSA fingerprint of this guard, without spaces.
  93. nickname (string)
  94. Declared nickname of this guard.
  95. sampled_on (Time in ISO YYYY-MM-DDTHH:MM:SS format)
  96. When was this guard added to the Guard sample?
  97. sampled_by (tor version)
  98. Which version of Tor added this Guard to the sample?
  99. (Used to help with debugging.)
  100. sampled_idx (integer)
  101. Index of this guard among sampled guards.
  102. listed (boolean)
  103. Did this guard appear in the most recent consensus?
  104. unlisted_since (Time in ISO YYYY-MM-DDTHH:MM:SS format)
  105. If this guard is not listed, when is the earliest
  106. consensus in which we found it unlisted?
  107. confirmed_on (Time in ISO YYYY-MM-DDTHH:MM:SS format)
  108. When did this guard become confirmed?
  109. confirmed_idx (integer)
  110. Index of this guard among confirmed guards.
  111. bridge_addr (address)
  112. If this guard is a bridge, its current address.
  113. pb_use_attempts
  114. pb_use_successes
  115. pb_circ_attempts
  116. pb_successful_circuits_closed
  117. pb_collapsed_circuits
  118. pb_unusable_circuits
  119. pb_timeouts
  120. Used by the pathbias subsystem to keep a record of the
  121. behavior of circuits built through this guard, in hopes of
  122. detecting guards try to that interfere with traffic.
  123. All of these fields are floating-point integers which
  124. represent a count of circuits that have been trated in
  125. various ways. These counts decay with time.
  126. "use_attempts" is a count of the circuits that we've built
  127. and tried to use for traffic.
  128. "successful_circuits_closed" is a count of circuits that
  129. have closed "naturally" without timeout or error.
  130. "use_successes" is a count of circuits that we've sent
  131. traffic on, and which closed "naturally" without timeout
  132. or error.
  133. "circ_attempts" is a count of circuits we've tried to
  134. build through this guard.
  135. "collapsed_circuits" is a count of circuits that failed
  136. after having been built, but before sending traffic.
  137. "unusable_circuits" is a count of circuits that we
  138. built, but where streams or probes but which failed,
  139. or which encountered questionable errors.
  140. "timeouts" is a count of circuits that encountered a
  141. timeout while we were building them.
  142. Obsolete fields include:
  143. EntryGuard
  144. EntryGuardDownSince
  145. EntryGuardUnlistedSince
  146. EntryGuardAddedBy
  147. These lines formed sections related to entry guards. Each section
  148. starts with a single EntryGuard line, and is then followed by
  149. information on the state of the Entry guard.
  150. The EntryGuard line contains a nickname, then an identity digest, of
  151. the guard.
  152. The EntryGuardDownSince and EntryGuardUnlistedSince lines are present
  153. if the entry guard is believed to be non-running or non-listed. If
  154. present, they contain a line in ISO format (YYYY-MM-DD HH:MM:SS).
  155. The EntryGuardAddedBy line is optional. It contains three
  156. space-separated fields: the identity of the entry guard, the version of
  157. Tor that added it, and the ISO time at which it was added.
  158. EntryGuardPathBias and EntryGuardPathUseBias are superseded by
  159. the `pb_...` elements in the Guard flag, and served a similar purpose.
  160. These entries have all been superseded by the Guard line type,
  161. since Tor 0.3.0.1-alpha.
  162. HidServRevCounter
  163. It was once used to ensure that v3 onion service directory revision
  164. numbers were strictly increasing; we now use an order-preserving
  165. encryption scheme for that purpose.
  166. This option could appear multiple times; each time it does, it
  167. applies to a different hidden service.