2012-03-28 10:08:07 +02:00
|
|
|
|
|
|
|
Contents of the Tor state file
|
|
|
|
==============================
|
|
|
|
|
|
|
|
The state file is structured with more or less the same rules as torrc.
|
|
|
|
Recognized fields are:
|
|
|
|
|
|
|
|
TorVersion
|
|
|
|
|
|
|
|
The version of Tor that wrote this file
|
|
|
|
|
|
|
|
LastWritten
|
|
|
|
|
|
|
|
Time when this state file was written.
|
|
|
|
Given in ISO format (YYYY-MM-DD HH:MM:SS)
|
|
|
|
|
2020-09-22 20:17:26 +02:00
|
|
|
|
|
|
|
MinutesSinceUserActivity (integer)
|
|
|
|
Dormant (0, 1, or "auto")
|
|
|
|
|
|
|
|
These values are used to keep track of how long Tor has been idle,
|
|
|
|
for the purpose of becoming 'dormant' after a long period without
|
|
|
|
any user-initiated requests.
|
|
|
|
|
|
|
|
"MinutesSinceUserActivity" is the number of minutes since the last
|
|
|
|
time the user asked us to do something. It is set to zero if we're
|
|
|
|
dormant.
|
|
|
|
|
|
|
|
"Dormant" is 1 if Tor was dormant when it wrote its state file, 0 if
|
|
|
|
Tor was active, and "auto" if Tor was starting for the first time.
|
|
|
|
|
2012-03-28 10:08:07 +02:00
|
|
|
AccountingBytesReadInInterval (memory unit)
|
|
|
|
AccountingBytesWrittenInInterval (memory unit)
|
|
|
|
AccountingExpectedUsage (memory unit)
|
|
|
|
AccountingIntervalStart (ISO time)
|
|
|
|
AccountingSecondsActive (time interval)
|
|
|
|
AccountingSecondsToReachSoftLimit (time interval)
|
|
|
|
AccountingSoftLimitHitAt (ISO time)
|
|
|
|
AccountingBytesAtSoftLimit (memory unit)
|
|
|
|
|
|
|
|
These fields describe the state of the accounting subsystem.
|
|
|
|
|
|
|
|
The IntervalStart is the time at which the current accounting
|
|
|
|
interval began. We were expecting to use ExpectedUsage over the
|
|
|
|
course of the interval. BytesRead/BytesWritten are the total
|
|
|
|
number of bytes transferred over the whole interval. If Tor has
|
|
|
|
been active during the interval, then AccountingSecondsActive is
|
|
|
|
the amount of time for which it has been active. We were expecting
|
|
|
|
to hit the bandwidth soft limit in SecondsToReachSoftLimit after we
|
|
|
|
became active. When we hit the soft limit, we record
|
|
|
|
BytesAtSoftLimit. If we hit the soft limit already, we did so at
|
|
|
|
SoftLimitHitAt.
|
|
|
|
|
|
|
|
TransportProxy
|
|
|
|
|
|
|
|
One or more of these may be present.
|
|
|
|
|
2012-03-31 14:33:11 +02:00
|
|
|
The format is "transportname addr:port", to remember the address
|
|
|
|
at which a pluggable transport was listening. Tor bridges use
|
|
|
|
this information to spawn pluggable transport listeners in the
|
|
|
|
same IP address and TCP port even after tor client restarts.
|
2012-03-28 10:08:07 +02:00
|
|
|
|
2020-09-22 20:17:26 +02:00
|
|
|
BWHistory___Ends (ISO time)
|
|
|
|
BWHistory___Interval (integer, number of seconds)
|
|
|
|
BWHistory___Values (comma-separated list of integer)
|
|
|
|
BWHistory___Maxima (comma-separated list of integer)
|
|
|
|
|
|
|
|
These values record bandwidth history. The "Values" fields are a list,
|
|
|
|
for some number of "Intervals", of the total amount read/written during
|
|
|
|
that integer. The "Maxima" are the highest burst for each interval.
|
2012-03-28 10:08:07 +02:00
|
|
|
|
|
|
|
Interval duration is set by the "Interval" field, in seconds. The
|
|
|
|
"Ends" field is the ending time of the last interval in each list.
|
|
|
|
|
2020-09-22 20:17:26 +02:00
|
|
|
Recognized values for "___" are:
|
|
|
|
Read -- total bytes read
|
|
|
|
Write -- total bytes written
|
|
|
|
DirRead -- total bytes read for directory connections.
|
|
|
|
DirWrite -- total bytes written for directory connections.
|
|
|
|
IPv6Read -- total bytes read on IPv6 connections
|
|
|
|
IPv6Write -- total bytes written on IPv6 connections
|
2012-03-28 10:08:07 +02:00
|
|
|
|
|
|
|
LastRotatedOnionKey
|
|
|
|
|
|
|
|
The last time that we changed our onion key for a new one.
|
|
|
|
Given in ISO format (YYYY-MM-DD HH:MM:SS)
|
|
|
|
|
2020-09-22 20:17:26 +02:00
|
|
|
This field is used to ensure that onion key rotations happen with the
|
|
|
|
appropriate frequency.
|
|
|
|
|
2012-03-28 10:08:07 +02:00
|
|
|
TotalBuildTimes
|
|
|
|
CircuitBuildAbandonedCount
|
|
|
|
CircuitBuildTimeBin
|
|
|
|
|
2020-09-22 20:44:30 +02:00
|
|
|
These fields are used by the Circuit Build Timeout code, which
|
|
|
|
tries to learn what times are reasonable for circuit construction,
|
|
|
|
so that it can reject circuits that take too long to build.
|
|
|
|
|
|
|
|
CircuitBuildTimeBin is a count of circuits that were build
|
|
|
|
successfully in some timeframe. This entry can repeat; each of
|
|
|
|
these represents some bar on a histogram. The first integer is a
|
|
|
|
number of milliseconds; it tells the position of the center of the
|
|
|
|
histogram bin on the time axis. The second number is a count of
|
|
|
|
circuits in that bin.
|
|
|
|
|
|
|
|
CircuitBuildTimeAbandonedCount is a count of circuits that we
|
|
|
|
simply gave up on building because they were taking far too long.
|
|
|
|
|
|
|
|
TotalBuildTimes is the number of circuit build times that we
|
|
|
|
observed in order to build the above measurements fields. If it
|
|
|
|
reaches a cap, then older measurements get thrown away.
|
2020-09-22 20:17:26 +02:00
|
|
|
|
|
|
|
Guard [key=value] [key=value]...
|
|
|
|
|
|
|
|
Describes a single entry guard used by the client. Key=value
|
|
|
|
entries with unrecognized keys are persisted. Order is not
|
|
|
|
significant. For more information about terminology used here,
|
|
|
|
system, see guard-spec.txt in the tor specifications repository.
|
|
|
|
|
|
|
|
Recognized keys are:
|
|
|
|
|
|
|
|
in (string)
|
|
|
|
|
|
|
|
The name of a guard selection that this guard is in.
|
|
|
|
|
|
|
|
rsa_id (string)
|
|
|
|
|
|
|
|
RSA fingerprint of this guard, without spaces.
|
|
|
|
|
|
|
|
nickname (string)
|
|
|
|
|
|
|
|
Declared nickname of this guard.
|
|
|
|
|
|
|
|
sampled_on (Time in ISO YYYY-MM-DDTHH:MM:SS format)
|
|
|
|
|
|
|
|
When was this guard added to the Guard sample?
|
|
|
|
|
|
|
|
sampled_by (tor version)
|
|
|
|
|
|
|
|
Which version of Tor added this Guard to the sample?
|
|
|
|
(Used to help with debugging.)
|
|
|
|
|
|
|
|
sampled_idx (integer)
|
|
|
|
|
|
|
|
Index of this guard among sampled guards.
|
|
|
|
|
|
|
|
listed (boolean)
|
|
|
|
|
|
|
|
Did this guard appear in the most recent consensus?
|
|
|
|
|
|
|
|
unlisted_since (Time in ISO YYYY-MM-DDTHH:MM:SS format)
|
|
|
|
|
|
|
|
If this guard is not listed, when is the earliest
|
|
|
|
consensus in which we found it unlisted?
|
|
|
|
|
|
|
|
confirmed_on (Time in ISO YYYY-MM-DDTHH:MM:SS format)
|
|
|
|
|
|
|
|
When did this guard become confirmed?
|
|
|
|
|
|
|
|
confirmed_idx (integer)
|
|
|
|
|
|
|
|
Index of this guard among confirmed guards.
|
|
|
|
|
|
|
|
bridge_addr (address)
|
|
|
|
|
|
|
|
If this guard is a bridge, its current address.
|
|
|
|
|
|
|
|
pb_use_attempts
|
|
|
|
pb_use_successes
|
|
|
|
pb_circ_attempts
|
|
|
|
pb_successful_circuits_closed
|
|
|
|
pb_collapsed_circuits
|
2020-09-22 20:35:11 +02:00
|
|
|
pb_unusable_circuits
|
2020-09-22 20:17:26 +02:00
|
|
|
pb_timeouts
|
|
|
|
|
2020-09-22 20:35:11 +02:00
|
|
|
Used by the pathbias subsystem to keep a record of the
|
|
|
|
behavior of circuits built through this guard, in hopes of
|
|
|
|
detecting guards try to that interfere with traffic.
|
|
|
|
|
|
|
|
All of these fields are floating-point integers which
|
|
|
|
represent a count of circuits that have been trated in
|
|
|
|
various ways. These counts decay with time.
|
|
|
|
|
|
|
|
"use_attempts" is a count of the circuits that we've built
|
|
|
|
and tried to use for traffic.
|
|
|
|
|
|
|
|
"successful_circuits_closed" is a count of circuits that
|
|
|
|
have closed "naturally" without timeout or error.
|
|
|
|
|
|
|
|
"use_successes" is a count of circuits that we've sent
|
|
|
|
traffic on, and which closed "naturally" without timeout
|
|
|
|
or error.
|
|
|
|
|
|
|
|
"circ_attempts" is a count of circuits we've tried to
|
|
|
|
build through this guard.
|
|
|
|
|
|
|
|
"collapsed_circuits" is a count of circuits that failed
|
|
|
|
after having been built, but before sending traffic.
|
|
|
|
|
|
|
|
"unusable_circuits" is a count of circuits that we
|
2020-09-22 22:51:26 +02:00
|
|
|
built, but where streams or probes but which failed,
|
2020-09-22 20:35:11 +02:00
|
|
|
or which encountered questionable errors.
|
|
|
|
|
|
|
|
"timeouts" is a count of circuits that encountered a
|
|
|
|
timeout while we were building them.
|
2020-09-22 20:17:26 +02:00
|
|
|
|
|
|
|
Obsolete fields include:
|
|
|
|
|
|
|
|
EntryGuard
|
|
|
|
EntryGuardDownSince
|
|
|
|
EntryGuardUnlistedSince
|
|
|
|
EntryGuardAddedBy
|
|
|
|
|
|
|
|
These lines formed sections related to entry guards. Each section
|
|
|
|
starts with a single EntryGuard line, and is then followed by
|
|
|
|
information on the state of the Entry guard.
|
|
|
|
|
|
|
|
The EntryGuard line contains a nickname, then an identity digest, of
|
|
|
|
the guard.
|
|
|
|
|
|
|
|
The EntryGuardDownSince and EntryGuardUnlistedSince lines are present
|
|
|
|
if the entry guard is believed to be non-running or non-listed. If
|
|
|
|
present, they contain a line in ISO format (YYYY-MM-DD HH:MM:SS).
|
|
|
|
|
|
|
|
The EntryGuardAddedBy line is optional. It contains three
|
|
|
|
space-separated fields: the identity of the entry guard, the version of
|
|
|
|
Tor that added it, and the ISO time at which it was added.
|
|
|
|
|
|
|
|
EntryGuardPathBias and EntryGuardPathUseBias are superseded by
|
|
|
|
the `pb_...` elements in the Guard flag, and served a similar purpose.
|
|
|
|
|
|
|
|
These entries have all been superseded by the Guard line type,
|
|
|
|
since Tor 0.3.0.1-alpha.
|
|
|
|
|
|
|
|
HidServRevCounter
|
|
|
|
|
|
|
|
It was once used to ensure that v3 onion service directory revision
|
|
|
|
numbers were strictly increasing; we now use an order-preserving
|
|
|
|
encryption scheme for that purpose.
|
|
|
|
|
|
|
|
This option could appear multiple times; each time it does, it
|
|
|
|
applies to a different hidden service.
|