<div dir="ltr">list unsubscribe *<br><br><div class="gmail_quote">On Sun, Jul 27, 2008 at 10:04 AM, Hans Schnehl <span dir="ltr"><<a href="mailto:torvallenator@gmail.com">torvallenator@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Thu, Jul 24, 2008 at 06:53:36AM -0500, Scott Bennett wrote:<br>
> I'm running 0.2.1.2-alpha and have noticed a recurring problem. It<br>
> appears that tor is sometimes not uploading a new descriptor on schedule.<br>
> Once this happens, it appears that it will *never* upload a descriptor<br>
> update on its own, though it can be tricked into doing so by making some<br>
> significant change in torrc, then giving it a SIGHUP. I've been trying<br>
> to keep an eye on it and forcing it to update when the authorities stop<br>
> listing it in the consensus documents by commenting/uncommenting an<br>
> ExitPolicy line and giving it SIGHUP.<br>
<br>
Very simular, on 0.2.0.28-rc (r15188) sending a SIGHUP did not do what<br>
it is supposed to.<br>
<br>
Trying to publish new descriptors (bandwidth) lead to quite unexpected<br>
results. The authorities (cached-consensus) simply stopped listing the<br>
node and cached-descriptors(.new) were not updated any more.<br>
This though did not have an immediate effect as there were enough machines<br>
using the node because of the previously downloaded descriptors and<br>
consensus. It simply died away slowly when more and more machines 'forgot'<br>
the node to exist.<br>
Some 12 hours later Tor had to be restartet when it was finally running<br>
on some 30% of its previous capacity, but then uploading the new<br>
descriptors then accepted (or recognized) correctly by the authorities.<br>
<br>
The second SIGHUP for to publish altered descriptors didn't do anything<br>
a few days later.<br>
The reason again was to increase bandwidth and to become a HSDir-Server.<br>
There might be things to be considered to set this flag I do not yet know,<br>
and if there are, let me know, please.<br>
The SIGHUP though did nothing at all.<br>
<br>
#/bin/kill -HUP 12345 && tail -f ../debug.log (info)<br>
<br>
showed the signal being recieved and new descriptors uploaded to I believe<br>
5 authorative servers, but only 4 responding. Some time later still no<br>
change could be seen, so a new and very unpatient SIGHUP did not have any<br>
result. I remember seeing this message:<br>
<br>
...Consensus does not include configured authority 'dannenberg' at .....<br>
<br>
but no change to the servers descriptors had been acknowledged.<br>
<br>
The altered descriptors were then correctly uploaded or recognized with the<br>
next schedule 18 hours after the previous one.<br>
<br>
I suppose Tor's behaviour to ignore SIGHUP uploads with an unmodified<br>
torrc may be rather a feature, but I'm not sure about this if Tor ignores<br>
signals which are sent for good reason.<br>
<br>
This on a FreeBSD amd64 box, Scott runs FreeBSD i386, does this also happen<br>
with linux's ?<br>
<br>
Bug or feature ? Happy ignoring ?<br>
<br>
Regards<br>
<font color="#888888">Hans<br>
</font><br>
P.S.: The moment I write this the box crashes hard. The reason for all<br>
this reconfiguring was to find the limit of this tiny server.<br>
Think I found it :)<br>
</blockquote></div><br></div>