Re: SIGHUP without effect

[Karsten Loesing <karsten.loesing@xxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Hans, Scott,

Hans Schnehl wrote:
| 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.

Correct. dir-spec.txt says that relays generate and upload a new router
descriptor when: "- Bandwidth has changed by a factor of 2 from the last
time a descriptor was generated, and at least a given interval of time
(20 mins by default) has passed since then." (They further do in other
situations, but this is the only one that is bandwidth-related.) The
directory authorities perform the same check when deciding whether or
not to store a router descriptor.

But you are right, this doesn't explain why Tor should stop publishing
descriptors afterwards.


Scott Bennett wrote:
|      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.

Ah, that's reasonable. Well, log statements are my primary source to see
that something is going wrong. So in this case I wondered which log
statement might have lead you to your conclusions. I didn't find one
that was directly related, so I asked if there was another one I might
have overlooked. After all, it could be something like "There is
something wrong with the descriptor I just wanted to upload, so I'll try
again later" (or something similar). So, it makes sense to turn on
logging in this case (probably even on debug level) to track down this bug.

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

Just to get this right: You changed your configuration once or multiple
times to force Tor to upload new descriptors, and at some time later
(about 18 hours) you realize that it has stopped publishing new
descriptors, correct? At that point even changes to your exit policy
don't make Tor publish a new descriptor any more, but you have to
restart it. (All of this should be fine to do, I'm just trying to
understand what is happening.)

Okay, I'll try to reproduce the bug myself and have a second look at the
code. However, if either of you finds out information that might help in
finding this bug, please share.

Thanks!
- --Karsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFImcLR0M+WPffBEmURAo9mAKCXg+7aQqQW4xdkP2cPIGVrY7NG9gCfQauy
a3T02ufl9vCEXqt14jt0p/I=
=2PjA
-----END PGP SIGNATURE-----