Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:18:54Zhttps://gitlab.torproject.org/legacy/trac/-/issues/5583Add option to overwrite logs2020-06-13T14:18:54ZbastikAdd option to overwrite logsAdd an option to make Tor overwrite logs, instead of appending them.
For instance whenever Tor gets restarted and this option is enabled the log does not get appended.*
This should enable operators to log without the risk of month old ...Add an option to make Tor overwrite logs, instead of appending them.
For instance whenever Tor gets restarted and this option is enabled the log does not get appended.*
This should enable operators to log without the risk of month old logs. Even when not enabled by default, what I was looking for in the first place, as I had not understood why logs are appending, it might help to have this option available.
The same applies to the client, once I was asked to provide logs from my client, and got told afterwards to remove the logging entry from torrc. When that does not happen, the client is logging for eternity and therefor provides an usage history due to the fact that the log is appending.
I couldn't pick "Tor" for "Component"; for me it's client and relay related.
*Other ways like, logging for a 24 hour period, keep this period and delete the lines that are older, might bring more problems than it's worth.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22723Avoid double-quoting esc_for_log output2020-06-13T15:10:40ZteorAvoid double-quoting esc_for_log outputIn #22368, arma posted a log where we double-quote relay nicknames.
```
[warn] There is a router named """" in my declared family, but that isn't a legal nickname. Skipping it.
```
Let's stop double-quoting esc_for_log output across the ...In #22368, arma posted a log where we double-quote relay nicknames.
```
[warn] There is a router named """" in my declared family, but that isn't a legal nickname. Skipping it.
```
Let's stop double-quoting esc_for_log output across the codebase.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/31707Better handling and UX for missing and expired guard descriptors2020-06-13T15:45:33ZteorBetter handling and UX for missing and expired guard descriptorsSplit off #31657:
Replying to teor:
> How do we reliably detect pathological cases?
> Suppress the message, until it occurs a few times within a short timeframe?
dgoulet:
That's a good question I don't have an answer for.
Unfortunate...Split off #31657:
Replying to teor:
> How do we reliably detect pathological cases?
> Suppress the message, until it occurs a few times within a short timeframe?
dgoulet:
That's a good question I don't have an answer for.
Unfortunately, I don't think that's the kind of message that occurs multiple times, looking at #30746 (and friends) this seems to be able to cause havoc with just a single repeatition.
I'm not sure why this is the case, since `router_have_minimum_dir_info()` seems to be called all the time and that should eventually call `entry_guards_get_err_str_if_dir_info_missing()` which is the source of the log message... Things are kinda messy between these two functions tho, so it's kinda hard to understand what's the issue.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19711circuit_package_relay_cell(): Bug: outgoing relay cell sent from src/or/relay...2020-06-13T14:59:38ZTraccircuit_package_relay_cell(): Bug: outgoing relay cell sent from src/or/relay.c:701 has n_chan==NULL. Dropping. (on Tor 0.2.8.5-rc )circuit_package_relay_cell(): Bug: outgoing relay cell sent from src/or/relay.c:701 has n_chan==NULL. Dropping. (on Tor 0.2.8.5-rc )
**Trac**:
**Username**: user100500circuit_package_relay_cell(): Bug: outgoing relay cell sent from src/or/relay.c:701 has n_chan==NULL. Dropping. (on Tor 0.2.8.5-rc )
**Trac**:
**Username**: user100500Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/9708Clarify "please raise ulimit -n" message2020-06-13T14:31:48ZTracClarify "please raise ulimit -n" messageMy logfiles often contained messages like:
- Error creating network socket: Too many open files in system
This happens when socket layer calls return ENFILE or EMFILE. Raising kern.maxfiles and kern.maxfilesperproc makes these messag...My logfiles often contained messages like:
- Error creating network socket: Too many open files in system
This happens when socket layer calls return ENFILE or EMFILE. Raising kern.maxfiles and kern.maxfilesperproc makes these messages go away, as expected. However, the following message kept happening:
- Failing because we have 11062 connections already. Please raise your ulimit -n. [8422 similar message(s) suppressed in last 21600 seconds]
I spent a long time looking into file descriptor limits because the value (11062) was suspiciously close to the maximum number of file descriptors per process (11095), which I just raised earlier. Then I discovered #define ERRNO_IS_ACCEPT_RESOURCE_LIMIT(e) in src/common/compat.h and that I had to look for ENOMEM and ENOBUFS in addition to ENFILE and EMFILE.
Reading through the socket code in the kernel, I found that FreeBSD has a default maximum accept() backlog of 128 connections. When more than that number of TCPs are in the syncache, accept() will fail with one of ENOMEM or ENOBUFS. I haven't spent the time to figure out which (it's a maze of twisty passages between kern/uipc_socket and netinet/tcp_usrreq.c -- neither of those are in my active brain cache).
The actual "solution" to the problem (allow tor to accept more connections, and thus make the message go away) was to raise kern.ipc.somaxconn.
The instruction to raise ulimit -n is definitely wrong for FreeBSD. Or at least only part of the story, and certainly cause for confusion. Perhaps the message should point to some generic documentation suggesting system limits/knobs to twiddle, rather than assuming that all the world is Linux and ulimit -n will work in every case.
**Trac**:
**Username**: philipTor: 0.2.6.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/21474Fix make test-fuzz-corpora warnings2020-06-13T15:06:22ZteorFix make test-fuzz-corpora warningsThe following bug warnings should probably be protocol warnings, or be caught earlier:
```
./src/test/fuzz_static_testcases.sh
Running tests for consensus
Feb 16 02:17:26.012 [warn] tor_timegm: Bug: Out-of-range argument to tor_timegm (o...The following bug warnings should probably be protocol warnings, or be caught earlier:
```
./src/test/fuzz_static_testcases.sh
Running tests for consensus
Feb 16 02:17:26.012 [warn] tor_timegm: Bug: Out-of-range argument to tor_timegm (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
Feb 16 02:17:30.133 [warn] sr_parse_commit: Bug: SR: Commit algorithm "sha6-256" is not recognized. (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
Feb 16 02:17:34.625 [warn] commit_decode: Bug: SR: Commit from authority 20EE989200EF98A75102B461DF62F01B2932C0D6 decoded length doesn't match the expected length (36 vs 40). (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
Feb 16 02:17:40.758 [warn] commit_decode: Bug: SR: Commit from authority B0F141F4B8CCBCC328572C71E5590BBA19775594 can't be decoded. (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
Running tests for descriptor
Feb 16 02:18:08.780 [warn] tor_timegm: Bug: Out-of-range argument to tor_timegm (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
Running tests for extrainfo
Feb 16 02:18:18.548 [warn] tor_timegm: Bug: Out-of-range argument to tor_timegm (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
...
```
I'm not sure whether we need this in 030, but it would be nice to fix them eventually.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18499Improved event selection dialog2016-07-05T00:50:14ZDamian JohnsonImproved event selection dialogTo select events to log Nyx uses a weird dialog, requiring users to pick letters corresponding with the events they want. To see it press 'e' on the first page...
![https://www.atagar.com/transfer/tmp/event_selection.png](https://www.at...To select events to log Nyx uses a weird dialog, requiring users to pick letters corresponding with the events they want. To see it press 'e' on the first page...
![https://www.atagar.com/transfer/tmp/event_selection.png](https://www.atagar.com/transfer/tmp/event_selection.png)
This was ok years ago when tor had few events, but as you can see this now requires the user to type really arcane strings ('CaruF'?). We should change this to be similar to our [config editor](https://www.atagar.com/arm/images/screenshot_configPanel_full.png), showing a dialog like...
```
+------------------------------------------------------+
| BW event |
| Bandwidth used by tor. This shows both the number of |
| bytes sent and received. |
+------------------------------------------------------+
| [ ] DEBUG |
| [ ] INFO |
| [X] NOTICE |
| [X] WARN |
| [X] ERR |
+------------------------------------------------------+
| [ ] BW |
| [ ] CIRC |
| ... etc... |
+------------------------------------------------------+
```
Note we'll be dropping the '--log' argument as part of this. A big part of the reason for this arcane alphabet soup was to allow users to specify events with that argument but this clunkiness is hardly worth it. Users can configure initial events in their nyxrc instead.Damian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31669Invalid signature for service descriptor signing key: expired2020-06-13T15:45:22ZTracInvalid signature for service descriptor signing key: expiredwhen searching for this log entry: #26932
The following log entry has been seen on exit relays running in OfflineMasterKey mode. Online keys did not expire, relay did not shutdown when this log entry was observed. We did not observe any...when searching for this log entry: #26932
The following log entry has been seen on exit relays running in OfflineMasterKey mode. Online keys did not expire, relay did not shutdown when this log entry was observed. We did not observe any service degradation.
```
Invalid signature for service descriptor signing key: expired
```
**Trac**:
**Username**: a_pTor: 0.4.3.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/7036Logs include milliseconds unnecessarily2020-06-13T14:23:22ZTracLogs include milliseconds unnecessarilySample:
Oct 03 22:57:57.000 [warn] Socks version 67 not recognized. (Tor is not an http proxy.)
**Trac**:
**Username**: joergentSample:
Oct 03 22:57:57.000 [warn] Socks version 67 not recognized. (Tor is not an http proxy.)
**Trac**:
**Username**: joergentTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21510Make unit test captured log messages consistent2020-06-13T15:06:32ZteorMake unit test captured log messages consistentThere's an extra colon and missing space in b0a9e54705d.
It would be nice to clean these up - there's no reason to backport.There's an extra colon and missing space in b0a9e54705d.
It would be nice to clean these up - there's no reason to backport.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/9802Obfsproxy shouldn't log raw network data2013-09-22T22:42:34ZPhilipp Winterphw@torproject.orgObfsproxy shouldn't log raw network dataCode in obfsproxy's `socks.py` logs raw network data which quickly inflates log files and messes with the terminal reading the log file.
The branch `nolog_raw` in this repository fixes this problem:
https://github.com/NullHypothesis/obf...Code in obfsproxy's `socks.py` logs raw network data which quickly inflates log files and messes with the terminal reading the log file.
The branch `nolog_raw` in this repository fixes this problem:
https://github.com/NullHypothesis/obfsproxyGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/31657Rephrase "missing descriptors" notice log to be less confusing2020-06-13T15:45:21ZteorRephrase "missing descriptors" notice log to be less confusingSome operators are confused or alarmed by these logs:
```
Sep 05 03:22:50.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/3 of our primary entry guards (total micro...Some operators are confused or alarmed by these logs:
```
Sep 05 03:22:50.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/3 of our primary entry guards (total microdescriptors: 6515/6541).
Sep 05 03:22:50.000 [notice] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/3 of our primary entry guards (total microdescriptors: 6515/6541).
```
We should rephrase them or document that:
* tor tries to keep active 3 primary guards for anonymity and safety
* we'll try to get new microdescs soon
* tor usually recovers quickly from this issueTor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/23090Sandbox failure on Debian 8.9 under OpenVZ with kernel version 2.6.322020-06-13T15:12:15ZteorSandbox failure on Debian 8.9 under OpenVZ with kernel version 2.6.32A relay operator reports a sandbox failure on Tor 0.3.0.9 with the following log lines:
```
sandbox_getaddrinfo(): (Sandbox) getaddrinfo succeeded.
sandbox_getaddrinfo(): (Sandbox) getaddrinfo failed.
sandbox_getaddrinfo(): (Sandbox) get...A relay operator reports a sandbox failure on Tor 0.3.0.9 with the following log lines:
```
sandbox_getaddrinfo(): (Sandbox) getaddrinfo succeeded.
sandbox_getaddrinfo(): (Sandbox) getaddrinfo failed.
sandbox_getaddrinfo(): (Sandbox) getaddrinfo succeeded.
install_syscall_filter(): Bug: (Sandbox) failed to load: -22 (Invalid argument)! (on Tor 0.3.0.9 )
tor_main(): Bug: Failed to create syscall sandbox filter (on Tor 0.3.0.9 )
main process exited, code=exited, status=1/FAILURE
```
See https://lists.torproject.org/pipermail/tor-relays/2017-August/012694.htmlTor: 0.3.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/9779Stem configs resetting to default2013-09-20T06:17:18ZcypherpunksStem configs resetting to defaultAfter some time, Tor receives a HUP signal (during a long period without any user interaction) and any configuration changes made in Stem are replaced with whatever is in the torrc file. Specifically, this change occurs at the precise mo...After some time, Tor receives a HUP signal (during a long period without any user interaction) and any configuration changes made in Stem are replaced with whatever is in the torrc file. Specifically, this change occurs at the precise moment that the tor log is rotated. Stem maintains authentication and can still communicate with tor...
My concern is with the purpose of Tor's HUP signal and the loss of any configuration made in Stem...
Example log tail:
.....
Sep 1 01:25:57.000 [notice] new bridge descriptor 'XXXXXX' (fresh): $0000000000000000000000000000000000000000~XXXXXX at 1.23.4.5
Sep 1 01:39:04.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Sep 1 01:39:04.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Sep 1 01:39:04.000 [notice] Read configuration file "/etc/tor/torrc".Damian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/10045Tor for Windows lacks eventlog support2020-06-13T14:32:46ZTracTor for Windows lacks eventlog supportTor for Windows does not support Windows' native system event logging facility "eventlog". Syslog is unsupported on Windows so an enhancement of Tor for Windows is necessary.
Administrators of Tor relays on Windows have a hard time of k...Tor for Windows does not support Windows' native system event logging facility "eventlog". Syslog is unsupported on Windows so an enhancement of Tor for Windows is necessary.
Administrators of Tor relays on Windows have a hard time of keeping track of Tor's events. This enhancement should ease this problem.
# Proposed changes/additions
## `/etc/torrc` or `%APPDATA%\tor\torrc`
* The `Log` configuration option's value `syslog` should enable logging to eventlog and be synonymous with the new value `eventlog` on Windows systems.
* A new `Log` configuration option value `eventlog` should be added. Setting `Log` to `eventlog` should enable logging to eventlog on Windows and be synonymous on other operating systems with the `syslog` value.
* Eventlog supports only four relevant event types for this matter: `EVENTLOG_SUCCESS`, `EVENTLOG_ERROR_TYPE`, `EVENTLOG_INFORMATION_TYPE`, and `EVENTLOG_WARNING_TYPE`. While `EVENTLOG_SUCCESS` usually maps to `EVENTLOG_INFORMATION_TYPE` leaving effectively three event types. These event types have to correspond to syslog's priorities/severities.
Proposed corresponding:
* `debug`, `info`, and `notice` correspond to `EVENTLOG_INFORMATION_TYPE`
* `warn` corresponds to `EVENTLOG_WARNING_TYPE`
* `err` corresponds to `EVENTLOG_ERROR_TYPE`
Verbosity should remain unaffected of priority/severity to event type correspondings, e.g. `notice` should not produce `info` or `debug` eventlog reports although they all correspond to the same event type `EVENTLOG_INFORMATION_TYPE`.
## Installing Tor as a service
* When installing Tor as service with "`tor.exe --service install`" tor should create an [event source](http://msdn.microsoft.com/en-us/library/aa363661%28v=vs.85%29.aspx) in the registry for eventlog.
* When removing the Tor service with "`tor.exe --service remove`" the previously created event source during service installation should be removed from registry.
**NOTE:** Generally speaking, this Tor installing as a service feature should be revised because by convention it is an uncommon practice on Windows for tools to provide such a feature. Service installation functionality is provided by the `sc.exe` external command and the Windows Installer (and the PowerShell lately). The preferred way for software vendors to install services is via the Windows Installer during application setup.
## Alternatives
Use a cross-platform logging library with good support for Windows.
**Trac**:
**Username**: GITNETor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20492Tor git version is not generated in git worktrees2020-07-31T12:44:02ZteorTor git version is not generated in git worktreesWhen I compile tor on macOS, it doesn't log the git version on startup:
```
Oct 29 01:27:48.261 [notice] Tor 0.3.0.0-alpha-dev running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
```
This happens regardless of ...When I compile tor on macOS, it doesn't log the git version on startup:
```
Oct 29 01:27:48.261 [notice] Tor 0.3.0.0-alpha-dev running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
```
This happens regardless of compiler and architecture:
gcc (MacPorts gcc49 4.9.4_0+universal) 4.9.4 (i386/x86_64)
clang version 3.9.0 (tags/RELEASE_390/final) (x86_64)
$ git --version
git version 2.10.1
But when I compile it on Linux, I see a git commit hash:
```
Oct 28 14:28:15.669 [notice] Tor 0.3.0.0-alpha-dev (git-f3e158edf7d8128d) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g and Zlib 1.2.8.
```
Compiler:
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
$ git --version
git version 2.6.3.36.g9a8c740
I'm putting this in 0.3.0 because it makes diagnosing issues much easier if we have the full commit. But feel free to disagree.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15607Tor log dates imprecise2020-06-15T23:32:36ZDamian JohnsonTor log dates impreciseHi Nick. Tor's log file uses the local timezone and lacks the year in its log file entries...
```
Apr 06 11:03:39.000 [notice] Tor 0.2.7.0-alpha-dev (git-4247ce99e5d9b7b2) opening new log file.
Apr 06 11:03:39.832 [notice] Tor v0.2.7.0-...Hi Nick. Tor's log file uses the local timezone and lacks the year in its log file entries...
```
Apr 06 11:03:39.000 [notice] Tor 0.2.7.0-alpha-dev (git-4247ce99e5d9b7b2) opening new log file.
Apr 06 11:03:39.832 [notice] Tor v0.2.7.0-alpha-dev (git-4247ce99e5d9b7b2) running on Linux with Libevent 2.0.16-stable, OpenSSL 1.0.1 and Zlib 1.2.3.4.
Apr 06 11:03:39.832 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
```
This is fine, but has meant some hacks for arm which reads the log file to prepopulate that information. For instance, arm pretends the year is always 2012 to ensure log files made on leap years are readable (otherwise February 29th isn't a thing, see #5265).
Feel free to close this as 'no plan to fix' if you'd like. Just thought I'd run this by you to see if iso8601 timestamps or something more complete would be preferable.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16070Tor log doesn't have to be world readable2020-06-13T14:46:19Zyurivict271Tor log doesn't have to be world readableCurrently log is:
> -rw-r--r-- 1 _tor _tor 3485 May 17 12:52 tor.log
tor-0.2.6.7Currently log is:
> -rw-r--r-- 1 _tor _tor 3485 May 17 12:52 tor.log
tor-0.2.6.7Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/12672Tor log should be accessible while Tor Browser is starting up2020-06-13T17:43:02ZTracTor log should be accessible while Tor Browser is starting upSometimes users write to the Help Desk saying that their Tor Browsers do not manage to start. Since it does not start and stops in the initial loading "Tor Status" screen displaying "Connecting to the Tor Network", users are unable to gr...Sometimes users write to the Help Desk saying that their Tor Browsers do not manage to start. Since it does not start and stops in the initial loading "Tor Status" screen displaying "Connecting to the Tor Network", users are unable to grab a log to send to the Help Desk.
**Trac**:
**Username**: EnviteKathleen BradeKathleen Bradehttps://gitlab.torproject.org/legacy/trac/-/issues/17971Unrecognized relay in exit address '[scrubbed].exit'. Refusing.2020-06-13T14:53:10ZcypherpunksUnrecognized relay in exit address '[scrubbed].exit'. Refusing.This line appeared in my tor log the other day.
> Unrecognized relay in exit address '[scrubbed].exit'. Refusing.
I don't know what it means, and a quick search didn't return anything useful. I wasn't doing anything out of the ordinary...This line appeared in my tor log the other day.
> Unrecognized relay in exit address '[scrubbed].exit'. Refusing.
I don't know what it means, and a quick search didn't return anything useful. I wasn't doing anything out of the ordinary; just using Tor Browser. I use the system-installed Tor, so it could have come from anything on the system I guess. Safe logging was enabled, so I don't know what address was requested.
When I tried to reproduce it by making an explicit request to foo.nonexistant.exit, I got this.
> The ".exit" notation is disabled in Tor due to security risks. Set AllowDotExit in your torrc to enable it (at your own risk).
What does the first line mean, and why wasn't the request rejected by AllowDotExit=0? Is this something I should be worried about? Even if it's benign, hopefully users who get this warning will find this ticket in searches, since I've been unable to find the exact message anywhere.Tor: unspecified