Re: SIGHUP without effect

[Karsten Loesing <karsten.loesing@xxxxxxx>]

-----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-----