Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:02:11Zhttps://gitlab.torproject.org/legacy/trac/-/issues/67We need to pass a string back along with the http status codes2020-06-13T14:02:11ZRoger DingledineWe need to pass a string back along with the http status codesThe dirserver gives back a status code (e.g. 403) plus a string. We need to make that string
configurable based on what the error/status actually is, and have the client parse out the
string.
Currently, there's no distinction between "y...The dirserver gives back a status code (e.g. 403) plus a string. We need to make that string
configurable based on what the error/status actually is, and have the client parse out the
string.
Currently, there's no distinction between "you're an unverified server" and "your clock is
extremely wrong". So people don't know there's anything to fix.
In addition, since we *do* accept unverified servers now, we should be giving back a "200 unverified server accepted" rather than a 403.
[Automatically added by flyspray2trac: Operating System: All]0.1.0.1-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/68Tor complains about missing epoll2020-06-13T14:02:11ZRoger DingledineTor complains about missing epollIt prints out
"tor: epoll_create: Function not implemented"
every time I start
on Red Hat FC1
Would it make sense to auto-detect better and/or disable epoll?
This will generate an unending stream of bug reports, as is.
[Automatically a...It prints out
"tor: epoll_create: Function not implemented"
every time I start
on Red Hat FC1
Would it make sense to auto-detect better and/or disable epoll?
This will generate an unending stream of bug reports, as is.
[Automatically added by flyspray2trac: Operating System: Other Linux]0.1.0.1-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/69Add flag to tor to verify config2020-06-13T14:02:11ZTracAdd flag to tor to verify configRight now if you edit the torrc incorrectly and HUP tor, it dies (and only says so in the log file so you
may not even notice for awhile. Anyways, it would be nice if tor had something equivalent to Apache's -t
flag which says "verify m...Right now if you edit the torrc incorrectly and HUP tor, it dies (and only says so in the log file so you
may not even notice for awhile. Anyways, it would be nice if tor had something equivalent to Apache's -t
flag which says "verify my config and tell me what if anything is broken". That way we could have a
torctl script which has a 'reload' option which would first verify the config and if OK, would HUP tor.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: synfinatic0.1.0.1-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/74Servers bloat memory from spawned children2020-06-13T14:02:11ZRoger DingledineServers bloat memory from spawned childrenWhen we fork, our children inherit the memory from the main Tor
process, which can be 50MB or more. Since it's copy-on-write, no
problem so far. But when the main Tor process changes the memory,
or frees it, then it gets copied so the ch...When we fork, our children inherit the memory from the main Tor
process, which can be 50MB or more. Since it's copy-on-write, no
problem so far. But when the main Tor process changes the memory,
or frees it, then it gets copied so the child has a clean copy.
So we end up using 50+MB per child. When we spawn a lot of dnsworkers,
this becomes really bad.
[Automatically added by flyspray2trac: Operating System: All]0.1.0.1-rchttps://gitlab.torproject.org/legacy/trac/-/issues/76don't ask unverified nodes for a directory2020-06-13T14:02:11ZRoger Dingledinedon't ask unverified nodes for a directoryUnverified nodes sometimes have really weird bandwidth shaping, and they also sometimes have
really wrong clocks. So asking them for a directory is just asking for trouble, and there are
enough other mirrors that we should be ok.
[Autom...Unverified nodes sometimes have really weird bandwidth shaping, and they also sometimes have
really wrong clocks. So asking them for a directory is just asking for trouble, and there are
enough other mirrors that we should be ok.
[Automatically added by flyspray2trac: Operating System: All]0.1.0.1-rchttps://gitlab.torproject.org/legacy/trac/-/issues/77clients are believing really old recommended-versions2020-06-13T14:02:11ZRoger Dingledineclients are believing really old recommended-versionsClients believe recommended-versions no matter how old the directory is.
Option one: don't check recommended-versions if massive clock skew is detected on the dir.
Option two: remember the timestamp of the last recommended-versions you...Clients believe recommended-versions no matter how old the directory is.
Option one: don't check recommended-versions if massive clock skew is detected on the dir.
Option two: remember the timestamp of the last recommended-versions you saw, and discard
newly received ones that are older than it.
Option three: both.
[Automatically added by flyspray2trac: Operating System: All]0.1.0.1-rc