Re: SIGHUP without effect
-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-
Re: SIGHUP without effect
Hmmm...I see Hans has already followed up to Karsten, so I'll respond by following up to Hans's message. On Tue, 5 Aug 2008 10:47:43 +0200 Hans Schnehl [EMAIL PROTECTED] wrote: 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. :) Bugs are both reported and discussed on or-talk all the time. That's one of the more useful things about the list, IMO, and helps serve as an early warning system. | 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? 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. 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. | 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. I suppose, but I thought there was a provision also for an update if a considerable increase in bandwidth usage over the previously reported value had happened. 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. And that, I confess, is something I have sometimes done as well. I do not know whether that activity is at all correlated with tor's occasional forgetfulness. | 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.
Re: SIGHUP without effect
-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-
Re: SIGHUP without effect (was: 0.2.1.2-alpha failing to upload descriptor updates automatically)
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. 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. Very simular, on 0.2.0.28-rc (r15188) sending a SIGHUP did not do what it is supposed to. 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. The second SIGHUP for to publish altered descriptors didn't do anything a few days later. The reason again was to increase bandwidth and to become a HSDir-Server. There might be things to be considered to set this flag I do not yet know, and if there are, let me know, please. The SIGHUP though did nothing at all. #/bin/kill -HUP 12345 tail -f ../debug.log (info) showed the signal being recieved and new descriptors uploaded to I believe 5 authorative servers, but only 4 responding. Some time later still no change could be seen, so a new and very unpatient SIGHUP did not have any result. I remember seeing this message: ...Consensus does not include configured authority 'dannenberg' at . but no change to the servers descriptors had been acknowledged. The altered descriptors were then correctly uploaded or recognized with the next schedule 18 hours after the previous one. I suppose Tor's behaviour to ignore SIGHUP uploads with an unmodified torrc may be rather a feature, but I'm not sure about this if Tor ignores signals which are sent for good reason. This on a FreeBSD amd64 box, Scott runs FreeBSD i386, does this also happen with linux's ? Bug or feature ? Happy ignoring ? Regards Hans P.S.: The moment I write this the box crashes hard. The reason for all this reconfiguring was to find the limit of this tiny server. Think I found it :)
Re: SIGHUP without effect (was: 0.2.1.2-alpha failing to upload descriptor updates automatically)
list unsubscribe * On Sun, Jul 27, 2008 at 10:04 AM, Hans Schnehl [EMAIL PROTECTED]wrote: 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. 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. Very simular, on 0.2.0.28-rc (r15188) sending a SIGHUP did not do what it is supposed to. 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. The second SIGHUP for to publish altered descriptors didn't do anything a few days later. The reason again was to increase bandwidth and to become a HSDir-Server. There might be things to be considered to set this flag I do not yet know, and if there are, let me know, please. The SIGHUP though did nothing at all. #/bin/kill -HUP 12345 tail -f ../debug.log (info) showed the signal being recieved and new descriptors uploaded to I believe 5 authorative servers, but only 4 responding. Some time later still no change could be seen, so a new and very unpatient SIGHUP did not have any result. I remember seeing this message: ...Consensus does not include configured authority 'dannenberg' at . but no change to the servers descriptors had been acknowledged. The altered descriptors were then correctly uploaded or recognized with the next schedule 18 hours after the previous one. I suppose Tor's behaviour to ignore SIGHUP uploads with an unmodified torrc may be rather a feature, but I'm not sure about this if Tor ignores signals which are sent for good reason. This on a FreeBSD amd64 box, Scott runs FreeBSD i386, does this also happen with linux's ? Bug or feature ? Happy ignoring ? Regards Hans P.S.: The moment I write this the box crashes hard. The reason for all this reconfiguring was to find the limit of this tiny server. Think I found it :)
