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

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

changed milestone to %Tor: 0.2.7.x-final

added component::core tor/tor milestone::Tor: 0.2.7.x-final nickm-deferred-20161017 owner::arma points::3 priority::medium resolution::fixed severity::normal sponsor::S-can status::closed tor-bridge tor-pt type::defect version::tor 0.2.6.5-rc labels

Somewhat related #5085 (closed).

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 (moved) 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".

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".

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 (moved)'s fix help this ticket? That is, what else are we waiting on here, and how can we move it forward?

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 (moved)'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.

Trac:
Milestone: N/A to Tor: 0.2.8.x-final

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

Trac:
Milestone: Tor: 0.2.8.x-final to Tor: 0.2.9.x-final

Trac:
Reviewer: N/A to N/A
Severity: N/A to Normal
Sponsor: N/A to N/A
Points: N/A to medium?

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

Trac:
Sponsor: N/A to SponsorS-can

Trac:
Keywords: N/A deleted, tor-bridge tor-pt added

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

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?

Trac:
Status: new to accepted
Owner: N/A to arma

Trac:
Points: medium? to 3

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.

Trac:
Milestone: Tor: 0.2.9.x-final to Tor: 0.3.0.x-final
Keywords: tor-bridge tor-pt deleted, nickm-deferred-20161017, tor-bridge, tor-pt added

Ok, I'm going to close this one since #15435 (moved) 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. :)

Trac:
Milestone: Tor: 0.3.0.x-final to Tor: 0.2.7.x-final
Resolution: N/A to fixed
Status: accepted to closed

closed

changed time estimate to 24h

mentioned in issue #15435 (moved)

moved to tpo/core/tor#15434 (closed)

mentioned in issue tpo/core/tor#15435 (closed)