[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #8908 [Tor]: Tor systemd socket activation support
#8908: Tor systemd socket activation support
-------------------------+--------------------------------------------------
Reporter: cypherpunks | Owner: intgr
Type: enhancement | Status: assigned
Priority: minor | Milestone: Tor: 0.2.5.x-final
Component: Tor | Version: Tor: unspecified
Keywords: | Parent:
Points: | Actualpoints:
-------------------------+--------------------------------------------------
Changes (by intgr):
* priority: normal => minor
* status: needs_review => assigned
* owner: cypherpunks => intgr
Comment:
> This actually looks reasonably solid
Thanks. It wasn't meant to be ready for merging yet, but it works well
enough for me and I wanted to get some feedback before I invest more time
into it.
> When Tor first starts after significant downtime, it needs to download
a pretty big amount of directory data, and build enough circuits for user
traffic. Does that happen fast enough to answer the request that made
systemd launch Tor?
I tried it by deleting /var/lib/tor and running "time torify wget
http://httpbin.org/ip -o/dev/null -O-"
Over five tries I got 27 seconds, 11s, 9s, 67s, 12s. I guess some
applications might hit timeouts at 67 seconds, but wget and Firefox don't
seem to have a problem.
> If this is incompatible with hibernation, shouldn't we detect its use
along with hibernation, and warn the user?
Well it should be fixed one way or another before merging. As mentioned in
the mailing list thread, we could keep the listening sockets open, but
simply reject new incoming connections.
> It appears that we do systemd socket discovery by default,
unconditionally. Can that be right?
I think that's fine. If it isn't started by systemd then the environment
vars will be unset and it will behave just like before.
> For example, it would also be nice to have the ability to write a little
launcher program that bound to some low ports, then did a setuid(tor-
daemon) and exec()d Tor
The interface used by systemd to pass in sockets is pretty generic (sets 2
environment vars, LISTEN_PID and LISTEN_FDS). I think it could be re-used
for that. TODO: documentation.
> Is there anything we can do to make this tested?
Sure, I'll try to figure something out.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8908#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs