Re: SIGHUP without effect

[Hans Schnehl <torvallenator@xxxxxxxxx>]

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. :)
> 
> | 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?
> 
> |> 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.
> 
> 
> 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. 

> | 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.
I did not (want to) try to reproduce the latter behaviour again yet, so 
presently there is nothing 'solid' to be filed. 

As soon as there are recurrences or any other noticable events I will try
to deliver more appropriate information in the right place.  



Regards

Hans