[tor-bugs] #8908 [Tor]: Tor systemd socket activation support

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon May 20 17:41:53 UTC 2013


#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


More information about the tor-bugs mailing list