On 06/25/2009 04:39 AM, Roger Dingledine wrote: > Is this with the tor rpm shipped by Fedora?
yes > We don't support (or use, > or like, or recommend) the fedora tor rpm. OK. Is this ideological, or because it's no good? I can work to fix the latter (I don't think anybody at Fedora wants a bad RPM). In my experience automatic security updates [aside: which are currently borked for the Fedora tor package, but that's another story, which I think I've gotten the right people to resolve at this point] are worth many trade-offs. People just don't do security updates the way we wish they would. > The right answer imo is how the deb package does it: > https://git.torproject.org/checkout/tor/master/debian/tor.init > Check out the wait_for_deaddaemon function: it basically checks each > second whether the process is still around, and returns when it's gone > (or 60 seconds have passed). this makes sense. > So I guess if you raise your ShutdownWaitLength, you'll want to tweak > the script. But that still seems better than the > "kill -INT, sleep 1, kill -9" strategy the rpm uses. agreed, do you see any reason not to extract ShutdownWaitLength from the config file? >> or, perhaps even better: fixing the server shutdown process so the old >> server can't take out the new server. > > Can you clarify what happens here? 'tor stop' finishes but Tor is still > running, so then 'tor start' fails to launch a new Tor, and then the > old Tor exits, and then you have no Tor running but you think you do? OK, so to be more clear: Let's call the old tor process we're taking down torA and the new one we want torB. 1) torA is sent an INT to tell it to stop. It begins its shutdown process. 2) The init script isn't waiting or watching, so it starts torB. Because torA is no longer bound to its listener port, torB can start up just fine. The init script is out of the picture now. 3) torA reaches ShutdownWaitLength time. It kills itself. <---guess 4) torB gets taken out by torA's final shutdown. At this point the init script's lockfiles reflect torB running, when actually no tor is running. So it behaves inappropriately. I realize there's no point in addressing the current Fedora RPM init script here, but assuming 4) is correct, it would seem that however torA is finding torB, it shouldn't do it that way. -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/ Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: b...@bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf