[tor-bugs] #28877 [Core Tor/Tor]: Paginate large controller commands like 'GETINFO desc/all-recent'
Tor Bug Tracker & Wiki
blackhole at torproject.org
Thu Dec 20 04:18:23 UTC 2018
#28877: Paginate large controller commands like 'GETINFO desc/all-recent'
--------------------------+--------------------------
Reporter: wagon | Owner: (none)
Type: defect | Status: assigned
Priority: Medium | Milestone:
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
--------------------------+--------------------------
Comment (by wagon):
> Do you have a SSD?
> I suspect this might be a matter of disk iops.
No, I don't have SSD. However, disk cache should work (further invocations
of the same commands are faster than the first ones, I think it is because
of disk cache). Now I cannot make an ideal test with the whole system
residing in RAM, but I copied Nyx/Stem directory to /tmp (which resides in
RAM) and compared it with my above initial tests. I didn't find any
difference. Shell is still at least two times faster than `tor-prompt`.
> Again, this command is reading fourteen megabytes of data from disk then
dumping it on the socket.
I thought this data is read from memory of tor process, i.e. from RAM. Are
you sure Tor makes request to hard drive each time it needs to provide
this data?
> get ran in low resource environments (arduino and such) where such
commands can easily block the control connection for tens of seconds to
minutes.
Do you think it also explains the crash of `tor-prompt --run 'GETINFO desc
/all-recent >/dev/null` command?
If pipe is used, shell will also break (this is the reason I had to use
descriptors in `test.sh`). For example, success of the command
{{{
( echo AUTHENTICATE \"pass\" ; echo GETINFO ns/all ; echo QUIT ) | nc
127.0.0.1 9051
}}}
depends on the time of invocation, existence of redirection to some file
or to `/dev/null`, weather, and so on. If I redirect the output of this
command to some file in RAM, I see that it stops after roughly 20k lines
are printed. However, it works nice with short output commands.
> these commands are no-gos if distributing an application more broadly.
I agree. Let us wait what Tor core people will say.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28877#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list