Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:14:33Zhttps://gitlab.torproject.org/legacy/trac/-/issues/23628Hibernation on period roll-over2020-06-13T15:14:33ZTracHibernation on period roll-overVersion 0.3.1.7 on Ubuntu
I've following config entries related to accounting:
```
AccountingMax 1639 GBytes
AccountingStart month 24 00:00
```
Today (24/09/17) I've discovered following log entries:
```
Sep 24 00:00:00.000 [notice] C...Version 0.3.1.7 on Ubuntu
I've following config entries related to accounting:
```
AccountingMax 1639 GBytes
AccountingStart month 24 00:00
```
Today (24/09/17) I've discovered following log entries:
```
Sep 24 00:00:00.000 [notice] Configured hibernation. This interval began at 2017-09-24 00:00:00; the scheduled wake-up time is 2017-09-28 16:44:28; we expect to exhaust our quota for this interval around 2017-10-21 20:52:28; the next interval begins at 2017-10-24 00:00:00 (all times local)
Sep 24 00:00:01.000 [notice] Commencing hibernation. We will wake up at 2017-09-28 16:44:28 local time.
Sep 24 00:00:01.000 [notice] Going dormant. Blowing away remaining connections.
Sep 24 00:20:47.000 [notice] Heartbeat: Tor's uptime is 5:59 hours, with 0 circuits open. I've sent 15.65 GB and received 15.63 GB. We are currently hibernating.
Sep 24 00:20:47.000 [notice] Circuit handshake stats since last time: 6985/6985 TAP, 162991/162991 NTor.
Sep 24 00:20:47.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 1 v3 connections, and 10218 v4 connections; and received 23 v1 connections, 3 v2 connections, 0 v3 connections, and 8412 v4 connections.
Sep 24 01:19:36.000 [notice] New control connection opened.
Sep 24 01:22:38.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Sep 24 01:22:38.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Sep 24 01:22:38.000 [notice] Read configuration file "/etc/tor/torrc".
Sep 24 01:22:38.000 [notice] Tor 0.3.1.7 (git-5fa14939bca67c23) opening log file.
Sep 24 01:22:38.000 [notice] Configured hibernation. This interval began at 2017-09-24 00:00:00; the scheduled wake-up time is 2017-09-28 16:44:28; we expect to exhaust our quota for this interval around 2017-10-21 20:52:28; the next interval begins at 2017-10-24 00:00:00 (all times local)
Sep 24 01:26:25.000 [notice] New control connection opened.
...
Sep 24 01:28:55.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Sep 24 01:28:55.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Sep 24 01:28:55.000 [notice] Read configuration file "/etc/tor/torrc".
Sep 24 01:28:55.000 [notice] Accounting period ended. This period, we will hibernate until 2017-09-28 11:00:28 UTC
Sep 24 01:28:55.000 [notice] Tor 0.3.1.7 (git-5fa14939bca67c23) opening log file.
Sep 24 01:28:56.000 [notice] Accounting period ended. This period, we will hibernate until 2017-09-28 11:00:28 UTC
Sep 24 01:28:57.000 [notice] Accounting period ended. This period, we will hibernate until 2017-09-28 11:00:28 UTC
...
Sep 24 01:30:11.000 [notice] SIGINT received while hibernating; exiting now.
Sep 24 01:32:36.000 [notice] Tor 0.3.1.7 (git-5fa14939bca67c23) opening log file.
Sep 24 01:32:36.727 [notice] Tor 0.3.1.7 (git-5fa14939bca67c23) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma 5.1.0alpha, and Libzstd N/A.
Sep 24 01:32:36.728 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Sep 24 01:32:36.729 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Sep 24 01:32:36.729 [notice] Read configuration file "/etc/tor/torrc".
Sep 24 01:32:36.735 [notice] Based on detected system memory, MaxMemInQueues is set to 1480 MB. You can override this by setting MaxMemInQueues by hand.
Sep 24 01:32:36.737 [notice] Opening OR listener on ...
Sep 24 01:32:37.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Sep 24 01:32:37.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Sep 24 01:32:37.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
Sep 24 01:32:38.000 [notice] Your Tor server's identity key fingerprint is ...
Sep 24 01:32:38.000 [notice] Bootstrapped 0%: Starting
Sep 24 01:33:16.000 [notice] Starting with guard context "default"
Sep 24 01:33:16.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Sep 24 01:33:16.000 [notice] Signaled readiness to systemd
Sep 24 01:33:16.000 [notice] Opening Control listener on /var/run/tor/control
Sep 24 01:33:16.000 [notice] Guessed our IP address as ...
Sep 24 01:33:16.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Sep 24 01:33:17.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Sep 24 01:33:17.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Sep 24 01:33:18.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Sep 24 01:33:18.000 [notice] Bootstrapped 100%: Done
Sep 24 01:33:46.000 [notice] New control connection opened.
Sep 24 01:34:18.000 [notice] Performing bandwidth self-test...done.
Sep 24 01:45:02.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Sep 24 01:45:02.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Sep 24 01:45:02.000 [notice] Read configuration file "/etc/tor/torrc".
Sep 24 01:45:02.000 [notice] Tor 0.3.1.7 (git-5fa14939bca67c23) opening log file.
Sep 24 01:45:02.000 [notice] Configured hibernation. This interval began at 2017-09-24 00:00:00; the scheduled wake-up time is 2017-09-28 16:44:28; we expect to exhaust our quota for this interval around 2017-10-21 20:52:28; the next interval begins at 2017-10-24 00:00:00 (all times local)
Sep 24 01:45:02.000 [notice] Not advertising Directory Service support (Reason: AccountingMax enabled)
Sep 24 01:45:03.000 [notice] Commencing hibernation. We will wake up at 2017-09-28 16:44:28 local time.
Sep 24 01:45:03.000 [notice] Going dormant. Blowing away remaining connections.
```
For context, Tor did not exceed previous (from 24/08-24/09) quota and was operating normally.
To me this is not what I would have expected as behaviour given the config. My exception is that the tor would reset counters at month end/beginning and continue operation in the new period. Currently Tor takes an unnecessary "nap" from 24/09 00:00 to 28/09 16:44.
What i've tried but with no success:
* reload config
* change pariod a few days & reload config
* restart tor
Only currently possible work-around is **disabling accounting**, but for me that is only a short time solution.
**Trac**:
**Username**: r1610091651@telenet.beTor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18852Directory mirrors should check accounting usage more frequently2020-06-13T14:56:34ZteorDirectory mirrors should check accounting usage more frequentlyAfter merging #12538 and #18616, Tor can wait up to 18 hours before checking whether the accounting usage has increase so much that we want to stop advertising DirPort and begindir support.
This is not great for relays with daily accoun...After merging #12538 and #18616, Tor can wait up to 18 hours before checking whether the accounting usage has increase so much that we want to stop advertising DirPort and begindir support.
This is not great for relays with daily accounting periods.
I suggest we check every hour to see whether the result of router_should_be_directory_server() has changed. If so, we should mark_my_descriptor_dirty() with an appropriate message about deciding to advertise or stop advertising directory service support / DirPort.
This likely also means separating the calculation part of router_should_be_directory_server() from the logging, otherwise we will log duplicate messages each time we change our minds about our accounting.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16636Add AccountingSetBytesRead/Written2020-06-13T14:47:32ZteorAdd AccountingSetBytesRead/WrittenA relay operator asked for the ability to reset the state file's `AccountingBytesReadInInterval` and `AccountingBytesWrittenInInterval` values.
While a workaround is to edit or delete the state file, perhaps command-line arguments `Acco...A relay operator asked for the ability to reset the state file's `AccountingBytesReadInInterval` and `AccountingBytesWrittenInInterval` values.
While a workaround is to edit or delete the state file, perhaps command-line arguments `AccountingSetRead` and `AccountingSetWritten` could be useful.
See also #15989 for `AccountingRule` `in` and `out`, as well as the `AccountingEnableDirPort` override.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/15380log messages are doubled and unclear2020-06-13T14:44:29Ztoralflog messages are doubled and unclearPlayed today with accounting and read in notice log :
```
Mar 19 18:49:51.000 [warn] You have set AccountingMax to use hibernation. You have also chosen a low DirPort or OrPort. This combination can make Tor stop working when it tries to...Played today with accounting and read in notice log :
```
Mar 19 18:49:51.000 [warn] You have set AccountingMax to use hibernation. You have also chosen a low DirPort or OrPort. This combination can make Tor stop working when it tries to re-attach the port after a period of hibernation. Please choose a different port or turn off hibernation unless you know this combination will work on your platform.
Mar 19 18:49:51.000 [warn] You have set AccountingMax to use hibernation. You have also chosen a low DirPort or OrPort. This combination can make Tor stop working when it tries to re-attach the port after a period of hibernation. Please choose a different port or turn off hibernation unless you know this combination will work on your platform.
Mar 19 18:49:51.000 [notice] Tor 0.2.6.5-rc (git-e0b77cd3194d705f) opening log file.
Mar 19 18:49:51.000 [warn] Failed to unlink /var/lib/tor/data/bw_accounting: No such file or directory
Mar 19 18:49:51.000 [notice] Configured hibernation. This interval begins at 2015-03-01 05:00:00 and ends at 2015-04-01 05:00:00. We have no prior estimate for bandwidth, so we will start out awake and hibernate when we exhaust our quota.
Mar 19 18:49:51.000 [notice] Not advertising DirPort (Reason: AccountingMax enabled)
```
Beside the doubling /me wonders why tor *warns* about DirPort (or ORPort) - but then *noticed* that it will ignore DirPort (anyway).Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/14066SIGHUP: Reloading config and does not reset internal state of accounting2020-06-13T14:41:26ZTracSIGHUP: Reloading config and does not reset internal state of accountingWrongly configured accounting and sent sighup to reload the config. Reload failed with below messages
Jan 1 08:22:50 NoNameForHost Tor[19880]: Option 'AccountingStart' used more than once; all but the last value will be ignored.
Jan 1...Wrongly configured accounting and sent sighup to reload the config. Reload failed with below messages
Jan 1 08:22:50 NoNameForHost Tor[19880]: Option 'AccountingStart' used more than once; all but the last value will be ignored.
Jan 1 08:22:50 NoNameForHost Tor[19880]: You have set AccountingMax to use hibernation. You have also chosen a low DirPort or OrPort. This combination can make Tor stop working when it tries to re-attach the port after a period of hibernation. Please choose a different port or turn off hibernation unless you know this combination will work on your platform.
Jan 1 08:22:50 NoNameForHost Tor[19880]: You have set AccountingMax to use hibernation. You have also chosen a low DirPort or OrPort. This combination can make Tor stop working when it tries to re-attach the port after a period of hibernation. Please choose a different port or turn off hibernation unless you know this combination will work on your platform.
Jan 1 08:22:50 NoNameForHost Tor[19880]: Caching new entry toranon for toranon
Jan 1 08:22:50 NoNameForHost Tor[19880]: Failed to unlink /var/lib/tor/bw_accounting: No such file or directory
Jan 1 08:22:50 NoNameForHost Tor[19880]: Configured hibernation. This interval begins at 2015-01-01 10:00:00 and ends at 2015-02-01 10:00:00. We have no prior estimate for bandwidth, so we will start out awake and hibernate when we exhaust our quota.
Jan 1 08:22:51 NoNameForHost Tor[19880]: Commencing hibernation. We will wake up at 2015-01-01 10:00:00 local time.
Jan 1 08:22:51 NoNameForHost Tor[19880]: Going dormant. Blowing away remaining connections.
Later I commented out accounting and sent sighup to reload the config but it does not reset internal state and keep on logging below messages.
Jan 1 08:23:23 NoNameForHost Tor[19880]: Accounting period ended. This period, we will hibernate until 2015-01-01 04:30:00 UTC
Jan 1 08:23:24 NoNameForHost Tor[19880]: Accounting period ended. This period, we will hibernate until 2015-01-01 04:30:00 UTC
I had to restart tor service to properly load config again.
**Trac**:
**Username**: SasiTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/9105make heartbeat messages describe hibernation consistently2020-06-13T14:29:55ZTracmake heartbeat messages describe hibernation consistentlyIf user have configured hibernation it looks like this:
```
03:02:02.000 [notice] Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted
06:19:04.000 [notice] Heartbeat: Tor's uptime is 18:00 hours, wi...If user have configured hibernation it looks like this:
```
03:02:02.000 [notice] Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted
06:19:04.000 [notice] Heartbeat: Tor's uptime is 18:00 hours, with 1 circuits open. I've sent 1.43 GB and received 1.45 GB. We are currently hibernating.
08:00:00.000 [notice] Configured hibernation. This interval began at 2013-06-20 08:00:00; the scheduled wake-up time was 2013-06-20 08:00:00; we expect to exhaust our quota for this interval around 2013-06-21 08:00:00; the next interval begins at 2013-06-21 08:00:00 (all times local)
08:00:00.000 [notice] Hibernation period ended. Resuming normal activity.
12:19:04.000 [notice] Heartbeat: Tor's uptime is 4:19 hours, with 45 circuits open. I've sent 1.58 GB and received 1.60 GB.
```
This is inconsistent. Upon hibernating Tor uptime is reset, but transferred GB are not. This does not make these messages useful.
It would be best to reset bw info on uptime reset after hibernation ended or report totals and current periods.
For example Running for XX hours (not reset on hibernation), total sent/received. Uptime is YY hours, sent/received data since last start.
If user have configured hibernation, i presume that he wants to know data sent/received in last hibernation interval.
**Trac**:
**Username**: hsnTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/4085We discard up to one second's worth of accounting bytes when time moves backw...2020-06-13T14:13:23ZRoger DingledineWe discard up to one second's worth of accounting bytes when time moves backward?In main.c's second_elapsed_callback() we do:
```
if (accounting_is_enabled(options) && seconds_elapsed >= 0)
accounting_add_bytes(bytes_read, bytes_written, seconds_elapsed);
```
So that means if our clock goes backwards, we don'...In main.c's second_elapsed_callback() we do:
```
if (accounting_is_enabled(options) && seconds_elapsed >= 0)
accounting_add_bytes(bytes_read, bytes_written, seconds_elapsed);
```
So that means if our clock goes backwards, we don't count whatever bytes we spent towards whether we should hibernate.
Is that actually wise? Does this situation happen often enough to matter? This bandwidth accounting stuff is messy.
(Noticed while reading patch for #3630)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/2003Hibernation Soft and Hard Limits Reached Simultaneously2020-06-13T14:06:56ZTracHibernation Soft and Hard Limits Reached Simultaneously0.2.2.17
AccountingMax 50GB
BarkerJrGarden1:
Oct 03 04:04:29.672 [notice] Bandwidth soft limit reached; commencing hibernation.
Oct 03 04:04:29.672 [notice] Going dormant. Blowing away remaining connections.
BarkerJrGarden2:
Oct 03 03...0.2.2.17
AccountingMax 50GB
BarkerJrGarden1:
Oct 03 04:04:29.672 [notice] Bandwidth soft limit reached; commencing hibernation.
Oct 03 04:04:29.672 [notice] Going dormant. Blowing away remaining connections.
BarkerJrGarden2:
Oct 03 03:13:23.971 [notice] Bandwidth soft limit reached; commencing hibernation.
Oct 03 03:13:23.971 [notice] Going dormant. Blowing away remaining connections.
**Trac**:
**Username**: BarkerJrTor: unspecifiedSebastian HahnSebastian Hahnhttps://gitlab.torproject.org/legacy/trac/-/issues/961TotalTraffic option (upload+download)2020-06-13T14:01:38ZTracTotalTraffic option (upload+download)Could a TotalTraffic option similar to AccountingMax be added?
I know, it isn't to hard to divide by two, but you usually need
to limit the sum of upload and download to not exceed your
traffic limit.
Maybe the description of Accounting...Could a TotalTraffic option similar to AccountingMax be added?
I know, it isn't to hard to divide by two, but you usually need
to limit the sum of upload and download to not exceed your
traffic limit.
Maybe the description of AccountingMax should also be changed to
make it clear, if one, either upstream traffic or downstream
traffic exceeds the limit Tor will hibernate.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: AthabaTor: 0.2.6.x-final