[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: ShutdownWaitLength vs. 'restart' in init scripts
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: bill@xxxxxxxxxxxxxxxx
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf