-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Scott, Hans,
this might indeed be a bug, or at least a behavior that should be changed. However, some more information about it would be helpful in finding out what exactly is wrong. The first thing is a description of what needs to be done in order to reproduce the problem. Is it just setting up a relay and, well, waiting? If so, how long does one have to wait? Can you provide your torrc files? Could you reproduce the behavior yourself after you experienced it the first time? What was the first Tor version that had this problem, and can you confirm that previous versions didn't have it? 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? | 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). Thanks! - --Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIlr800M+WPffBEmURAtdfAKCGnTNxge5FiOLqlzkVlilzssd4nACgwWB5 dOfs2+JRGiTbRHYb+8l0mT4= =DBNp -----END PGP SIGNATURE-----