Re: SIGHUP without effect

[Scott Bennett <bennett@xxxxxxxxxx>]

     Hmmm...I see Hans has already followed up to Karsten, so I'll respond
by following up to Hans's message.
     On Tue, 5 Aug 2008 10:47:43 +0200 Hans Schnehl <torvallenator@xxxxxxxxx>
wrote:
>On Mon, Aug 04, 2008 at 10:35:00AM +0200, Karsten Loesing wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>
>
>
>Hi  
>
>As this was started on this list, I continue here for now.
>
>
>[snip]
>> At some time, preferably when we have more information about what's
>> going on, someone should open a flyspray task for this bug. or-talk is
>> not the best place to discuss bugs. :)

     Bugs are both reported and discussed on or-talk all the time.  That's
one of the more useful things about the list, IMO, and helps serve as an
early warning system.
>> 
>> | On Thu, Jul 24, 2008 at 06:53:36AM -0500, Scott Bennett wrote:
>> |>      I'm running 0.2.1.2-alpha and have noticed a recurring problem.  It
>> |> appears that tor is sometimes not uploading a new descriptor on schedule.
>> 
>> How did you figure that out? Could you paste the log statements?

     I first noticed that traffic had dropped to only a few, occasional
packets per second (not even every second).  I then checked the most recent
consensus and status documents and found that MYCROFTsOtherChild was missing
from them.  What log statements did you have in mind?  Perhaps something like
"Oops!  I forgot to upload an updated descriptor, so I'm going into hiding"?
It forgot to do it, so it had nothing to log.  That was the next thing I
checked.  If left unmolested, tor normally uploads a new descriptor to the
authorities about every eighteen hours, but if it forgets to do that, then
that's pretty much the death knell of its usefulness until it has been
restarted.  Giving it a SIGHUP at this point does not then cause a new
descriptor to be uploaded, apparently regardless of ExitPolicy changes.
>> 
>> |> Once this happens, it appears that it will *never* upload a descriptor
>> |> update on its own, though it can be tricked into doing so by making some
>> |> significant change in torrc, then giving it a SIGHUP.  I've been trying
>> |> to keep an eye on it and forcing it to update when the authorities stop
>> |> listing it in the consensus documents by commenting/uncommenting an
>> |> ExitPolicy line and giving it SIGHUP.
>> 
>> The explanation might be that the authorities don't store router
>> descriptors when changes are considered cosmetic. However, after 12
>> hours time difference between storing two descriptors, changes should
>> never be considered cosmetic, regardless of how subtle they are.
>> 
     I suppose, but I thought there was a provision also for an update if
a considerable increase in bandwidth usage over the previously reported
value had happened.
>> 
>> Hans Schnehl wrote:
>> | Very simular, on 0.2.0.28-rc (r15188) sending a SIGHUP did not do what
>> | it is supposed to.
>> 
>> Okay, so what is SIGHUP supposed to do here? From the manpage:
>> 
>> "SIGHUP The signal instructs Tor to reload its configuration (including
>> closing and reopening logs), fetch a new directory, and kill and restart
>> its helper processes if applicable."
>> 
>> I might be wrong, but as far as I understand this, sending a HUP signal
>> does not necessarily include uploading a new descriptor that is then
>> accepted by the authorities. Why should this happen if the currently
>> stored descriptor is fine?
>
>By rereading a modified torrc, this signal causes tor also to upload
>these modifications to the authorities.
>What I tried to achieve is getting closer to the servers upper limits 
>in bandwidth/performance, therefore publishing descriptors with different
>bandwidths, sometimes within relatively short times. What I did not know
>is the authorities' not accepting so called 'cosmetic' changes within a
>certain timeframe. This is perfectly logic and makes sense, explains 
>most my observations, though not all. 

     And that, I confess, is something I have sometimes done as well.  I do
not know whether that activity is at all correlated with tor's occasional
forgetfulness.
>
>> | Trying to publish new descriptors (bandwidth) lead to quite unexpected
>> | results. The authorities (cached-consensus) simply stopped listing the
>> | node and cached-descriptors(.new) were not updated any more.
>> | This though did not have an immediate effect as there were enough
>> machines
>> | using the node because of the previously downloaded descriptors and
>> | consensus.  It simply died away slowly when more and more machines
>> 'forgot'
>> | the node to exist.
>> | Some 12 hours later Tor had to be restartet when it was finally running
>> | on some 30% of its previous capacity, but then uploading the new
>> | descriptors then accepted (or recognized) correctly by the authorities.
>> 
>> Well, this behavior is not intended. It would be quite interesting to
>> figure out when this situation occurs. Please provide more information
>> (as stated at the top of this mail).
>
>Unfortunately there isn't even a log of the incident, nor did it happen
>again, but that may be due to not using SIGHUP that often anymore now.

     Hans, the "missing" log messages aren't there because they were never
written to your log.  That's not due to any failure on your part.  tor simply
didn't do anything (about uploading a descriptor) that would have needed to
be logged.

>I did not (want to) try to reproduce the latter behaviour again yet, so 
>presently there is nothing 'solid' to be filed. 

     Again, I'm not at all sure that there is anything we could "do" to
reproduce the situation, though there is admittedly a chance that you could
be onto something about SIGHUP triggering a problem that doesn't become
noticeable till later on.  I just don't remember whether I had done that
before any of the times that tor failed to do the upload at the normal times.
>
>As soon as there are recurrences or any other noticable events I will try
>to deliver more appropriate information in the right place.  
>
     Likewise.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************