[tor-bugs] #25761 [Core Tor/Tor]: hs: Reload signal (HUP) doesn't remove a disabled service
Tor Bug Tracker & Wiki
blackhole at torproject.org
Sat May 5 11:59:32 UTC 2018
#25761: hs: Reload signal (HUP) doesn't remove a disabled service
-------------------------------------------------+-------------------------
Reporter: dgoulet | Owner: dgoulet
Type: defect | Status:
| accepted
Priority: Medium | Milestone: Tor:
| 0.3.4.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: 032-backport, 033-backport, tor-hs, | Actual Points:
regression |
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by asn):
I spent an hour today doing some debugging here. The main issue that
causes the bug here is that when we enter `rend_service_prune_list()`
after the HUP, to shutdown old services, we encounter
`rend_service_staging_list` being `NULL` and we stop the pruning by
hitting:
{{{
/* Don't try to prune anything if we have no staging list. */
if (!rend_service_staging_list) {
return;
}
}}}
Seems like `rend_service_staging_list` gets `NULL`ed during the initial
service configuration (before the HUP) in
`rend_service_prune_list_impl_()` with:
{{{
/* Finally, nullify the staging list pointer as we don't need it anymore
* and it needs to be NULL before the next reload. */
rend_service_staging_list = NULL;
}}}
and then nothing actually sets up the staging list after the HUP because
we are not adding any services, so we skip the post-HUP pruning...
I guess what we need to do is to setup the staging list even when we have
0 services to configure? Or alternatively, don't check for
`!rend_service_prune_list` when pruning? Need to dig more into this...
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25761#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list