Opened 5 years ago

Closed 3 years ago

#15434 closed defect (fixed)

Tor dies if you send it a HUP before it read its config, and doesn't take PTs with it

Reported by: TvdW Owned by: arma
Priority: Medium Milestone: Tor: 0.2.7.x-final
Component: Core Tor/Tor Version: Tor: 0.2.6.5-rc
Severity: Normal Keywords: tor-bridge, tor-pt, nickm-deferred-20161017
Cc: Actual Points:
Parent ID: Points: 3
Reviewer: Sponsor: SponsorS-can

Description

When sending tor a HUP before it has read its config, it will die, without killing its PTs. Starting tor again will then result in more PT crashes, as the ports will already be used by previous instances.

10149 ?        Sl     0:00 /usr/bin/obfs4proxy managed
10581 ?        Sl     0:01 /usr/bin/tor -f /etc/tor/torrc-node1
10582 ?        S      0:00  \_ /usr/bin/python /usr/bin/obfsproxy managed
10583 ?        Z      0:00  \_ [obfs4proxy] <defunct>
10584 ?        S      0:00  \_ /usr/bin/python /usr/bin/fteproxy --managed --mode server

Child Tickets

Change History (14)

comment:1 Changed 5 years ago by yawning

Somewhat related #5085.

I believe the issue is generic, and not obfs4proxy specific on the pt side. I suspect obfs4proxy is prone to displaying issues here because it's managing to get through the managed pt configuration protocol before tor crashes, while obfsproxy and fte (in the example), are slower to start up and fail to write the response over stdout.

In theory something like #10047 could be done PT side if tor didn't close the stdin on the PT process, and I'm strongly tempted to add a "PT_EXIT_ON_STDIN_CLOSE" env var to the pt protocol to facilitate this.

All of this is orthogonal to "tor shouldn't crash on an early HUP".

comment:2 in reply to:  1 Changed 4 years ago by arma

Replying to yawning:

All of this is orthogonal to "tor shouldn't crash on an early HUP".

Tom-or-somebody, did this part get its own ticket?

Or is this simply a case of "it hasn't registered its signal handlers yet, what do you expect. Can't-fix".

comment:3 in reply to:  1 ; Changed 4 years ago by arma

Replying to yawning:

I'm strongly tempted to add a "PT_EXIT_ON_STDIN_CLOSE" env var to the pt protocol to facilitate this.

How much does #15435's fix help this ticket? That is, what else are we waiting on here, and how can we move it forward?

comment:4 in reply to:  3 Changed 4 years ago by yawning

Replying to arma:

Replying to yawning:

I'm strongly tempted to add a "PT_EXIT_ON_STDIN_CLOSE" env var to the pt protocol to facilitate this.

How much does #15435's fix help this ticket? That is, what else are we waiting on here, and how can we move it forward?

That should be it. It's worth noting that the latest release of obfs4proxy, and newer versions of tor both have also special code to attempt to have PTs self terminate even without the env var (via PR_SET_PDEATHSIG, and ppid monitoring). Windows is kind of stuck, but that's what the env var is for.

comment:5 Changed 4 years ago by nickm

Milestone: Tor: 0.2.8.x-final

comment:6 Changed 4 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final

Throw most 0.2.8 "NEW" tickets into 0.2.9. I expect that many of them will subsequently get triaged out.

comment:7 Changed 4 years ago by nickm

Points: medium?
Severity: Normal

comment:8 Changed 4 years ago by nickm

Sponsor: SponsorS-can

Tagging these bridge- and PT- items as S-can.

comment:9 Changed 4 years ago by nickm

Keywords: tor-bridge tor-pt added

comment:10 Changed 4 years ago by arma

I think we might want to close this one, either as resolved or as a duplicate of #15435?

Or we can retitle it to simply "Tor dies if you send it a HUP before it read its config", but isn't that both kind of expected and also kind of unfixable?

comment:11 Changed 3 years ago by arma

Owner: set to arma
Status: newaccepted

comment:12 Changed 3 years ago by isabela

Points: medium?3

comment:13 Changed 3 years ago by nickm

Keywords: nickm-deferred-20161017 added
Milestone: Tor: 0.2.9.x-finalTor: 0.3.0.x-final

I am fairly sure that these are neither regressions nor major problems. So, deferring from 0.2.9. Please let me know if I'm wrong.

comment:14 Changed 3 years ago by arma

Milestone: Tor: 0.3.0.x-finalTor: 0.2.7.x-final
Resolution: fixed
Status: acceptedclosed

Ok, I'm going to close this one since #15435 resolved the "and doesn't take PTs with it" part.

I was going to file a separate ticket for "Tor doesn't catch HUP until a while after it's started up", but I just looked through the code, and we don't register our signal handlers until after we've done our fork(), and we don't decide whether to fork() until we've read our torrc to find out if we're going to. I guess we could register the handlers before we fork... but that is going to get ugly, and we have plenty of more important things to do. Please make that ticket if you disagree. :)

Note: See TracTickets for help on using tickets.