Hello all As written above, I run an Exit (for many years, with the current setup since 04.2019) but on 30. March 2020 it stopped, I was unable to determine any reason. So I installed updates and since there were some Kernel updates I also rebooted the machine. The Exit was back up and ran again till ~36h ago. Same situation again, I have no idea why it stopped.
I now activated "Log notice syslog", I think this was in the standard torrc which is installed with the package of Ubuntu 18.04.4 LTS anyway, but there is not entries in journalctl. Only Start/Stop/Reload events are shown in the journal for unit tor.service since 100 day ago.
Can someone help me to troubleshoot this problem, could the fingerprint be blacklisted? In this case would the Exit come back up running for a few days as described above?
Regards and thank you very much for any support. yl
I can add some information I forgot before. In "nyx" it showed my that the Relay had no flags, now after another reboot it show at least "Exit, Fast, Running, V2Dir, Valid" again, I think the other flags were lost due to the relay being kind of offline. Currently nyx shows about 4 MB/sec, not very much.
Regards yl
On 4/7/20 12:37 PM, ylms wrote:
Hello all As written above, I run an Exit (for many years, with the current setup since 04.2019) but on 30. March 2020 it stopped, I was unable to determine any reason. So I installed updates and since there were some Kernel updates I also rebooted the machine. The Exit was back up and ran again till ~36h ago. Same situation again, I have no idea why it stopped.
I now activated "Log notice syslog", I think this was in the standard torrc which is installed with the package of Ubuntu 18.04.4 LTS anyway, but there is not entries in journalctl. Only Start/Stop/Reload events are shown in the journal for unit tor.service since 100 day ago.
Can someone help me to troubleshoot this problem, could the fingerprint be blacklisted? In this case would the Exit come back up running for a few days as described above?
Regards and thank you very much for any support. yl _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi,
On 7 Apr 2020, at 21:34, ylms tor@yl.ms wrote:
As written above, I run an Exit (for many years, with the current setup since 04.2019) but on 30. March 2020 it stopped, I was unable to determine any reason.
Have you checked tor's logs? They are usually in /var/log/tor/log
If you have logrotate configured, they might have already been deleted, because 30 March is more than 1 week ago.
So I installed updates and since there were some Kernel updates I also rebooted the machine. The Exit was back up and ran again till ~36h ago. Same situation again, I have no idea why it stopped.
I now activated "Log notice syslog", I think this was in the standard torrc which is installed with the package of Ubuntu 18.04.4 LTS anyway, but there is not entries in journalctl. Only Start/Stop/Reload events are shown in the journal for unit tor.service since 100 day ago.
Have you tried reading /var/log/sys log directly?
Can someone help me to troubleshoot this problem, could the fingerprint be blacklisted? In this case would the Exit come back up running for a few days as described above?
Most of the time, blacklisting just makes Tor log a message in its logs. And the directory authorities stop publishing the relay in the consensus.
(We haven't made any changes to required protocols recently. If we do, very old Tor versions may shut down.)
Here's what we need to know to be more helpful: * your relay fingerprint * your Tor version * tor's logs when it shuts down
T
Hello Teor
On 4/7/20 11:24 PM, teor wrote:
Hi,
On 7 Apr 2020, at 21:34, ylms tor@yl.ms wrote:
As written above, I run an Exit (for many years, with the current setup since 04.2019) but on 30. March 2020 it stopped, I was unable to determine any reason.
Have you checked tor's logs? They are usually in /var/log/tor/log
The directory /var/log/tor/ is empty, I think the Debian/Ubuntu package logs to syslog per default, but not sure, I cant find anything besides start/stop/reload in the sys log (journalctl to view it).
If you have logrotate configured, they might have already been deleted, because 30 March is more than 1 week ago.
Funnily there is a logrotate job for the folder, it is: /var/log/tor/*log { daily rotate 5 compress delaycompress missingok notifempty create 0640 debian-tor adm sharedscripts postrotate if invoke-rc.d tor status > /dev/null; then invoke-rc.d tor reload > /dev/null fi endscript }
Which would have removed the file as you point out, but still there should be some logs from 3 days ago when it happened again. But as stated above the folder is empty.
So I installed updates and since there were some Kernel updates I also rebooted the machine. The Exit was back up and ran again till ~36h ago. Same situation again, I have no idea why it stopped.
I now activated "Log notice syslog", I think this was in the standard torrc which is installed with the package of Ubuntu 18.04.4 LTS anyway, but there is not entries in journalctl. Only Start/Stop/Reload events are shown in the journal for unit tor.service since 100 day ago.
Have you tried reading /var/log/sys log directly?
Thanks, that was my mistake, I didn't look in the file, but was just looking for tor.service unit entries, but of course the application itself just logs as "tor" or "Tor" and not as tor.service.
So I see some info there, but nothing helpful since I just activated logging yesterday. I will revisit this in a few days when/if the problem occurs again, also I increased the rotation for the log to 14 days and am now logging into /var/log/tor/log.
Could you advise which loglevel I should use to troubleshoot this? I set notice for now, because debug generated too much data.
Can someone help me to troubleshoot this problem, could the fingerprint be blacklisted? In this case would the Exit come back up running for a few days as described above?
Most of the time, blacklisting just makes Tor log a message in its logs. And the directory authorities stop publishing the relay in the consensus.
(We haven't made any changes to required protocols recently. If we do, very old Tor versions may shut down.)
Here's what we need to know to be more helpful:
- your relay fingerprint
- your Tor version
- tor's logs when it shuts down
Thanks again for the help, it is much appreciated.
Regards yl
On Wed, Apr 08, 2020 at 09:40:39AM +0200, ylms wrote:
So I see some info there, but nothing helpful since I just activated logging yesterday. I will revisit this in a few days when/if the problem occurs again, also I increased the rotation for the log to 14 days and am now logging into /var/log/tor/log.
Great.
Could you advise which loglevel I should use to troubleshoot this? I set notice for now, because debug generated too much data.
Notice-level logs are a fine default. They should include everything that's important for you to hear about, but also they try hard not to include sensitive information.
See this item from the old faq, which didn't get migrated to the new support portal: https://2019.www.torproject.org/docs/faq#LogLevel
--Roger
Hello Roger
On 4/8/20 10:53 AM, Roger Dingledine wrote:
Notice-level logs are a fine default. They should include everything that's important for you to hear about, but also they try hard not to include sensitive information.
See this item from the old faq, which didn't get migrated to the new support portal: https://2019.www.torproject.org/docs/faq#LogLevel
I did read that, but wasn't sure which level is sufficient, but am now sure that debug is not a good logging level for a running relay, it will create 450 GB logs a day.
As you also suggested I did set notice now.
Regards yl
Hello Roger, hello all
I got the problem again, again I missed it and it was 6 day and 3 hours ago since the relay is said to be offline. (atlas)
Nyx says all is fine, but all flags are gone, there is nothing the log, just the transmitted data stopped to increase, so since 5 TB were reached nothing is moving anymore.
Nothing in the dmesg that looks strange, as well as in the journalctl, nothing for the time rage of 9-6 days back.
I am too tired now to look into it, but I would love to get some requests for information to supply and will look to supply all info needed. The server is still in the error state.
I am very thankful for help.
Regards yl
On 08/04/2020 10:53, Roger Dingledine wrote:
On Wed, Apr 08, 2020 at 09:40:39AM +0200, ylms wrote:
So I see some info there, but nothing helpful since I just activated logging yesterday. I will revisit this in a few days when/if the problem occurs again, also I increased the rotation for the log to 14 days and am now logging into /var/log/tor/log.
Great.
Could you advise which loglevel I should use to troubleshoot this? I set notice for now, because debug generated too much data.
Notice-level logs are a fine default. They should include everything that's important for you to hear about, but also they try hard not to include sensitive information.
See this item from the old faq, which didn't get migrated to the new support portal: https://2019.www.torproject.org/docs/faq#LogLevel
--Roger
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Thu, Apr 30, 2020 at 11:14:11PM +0200, yl wrote:
I am too tired now to look into it, but I would love to get some requests for information to supply and will look to supply all info needed. The server is still in the error state.
Did you ever tell us a fingerprint (and/or nickname) for your relay?
My first question would be whether the relay has an IPv6 ORPort, because maybe that address became unreachable.
--Roger
Hello Roger
On 5/1/20 12:15 AM, Roger Dingledine wrote:
My first question would be whether the relay has an IPv6 ORPort, because maybe that address became unreachable.
Thanks for this question. This was it it seems. Still I can't see any problem and am not able to find the reason, but this now seems to be out of tors scope.
For now it is an IPv4 only Exit, better than nothing. 7
Anyone here who has an idea why Ubuntu with netplan suddenly refuses IPv6 connection, while internally a Ping6 to the servers IPv6 still works, please let me know your idea!
Very thankful for any help. yl
Not sure what your issue with Ubuntu is, I'm running 20.04 and have no issues with inbound/outbound IPV4/6 connections. It kind of seems to me that the Tor relays just love to nitpick. While I'm here though I do have one question for you lads and laddettes.
Is running a Tor relay on Tails a good idea? I would think not due to the philosophy of Tails, being it's not meant for long uptimes and I'm guessing a relay through the Tor network itself just is not compatible, but maybe one of you more educated relay admins can tell me better. P. S. I like the title of Tor relay admin, sounds cool haha -------- Original Message -------- On May 11, 2020, 10:13, ylms wrote:
Hello Roger
On 5/1/20 12:15 AM, Roger Dingledine wrote:
My first question would be whether the relay has an IPv6 ORPort, because maybe that address became unreachable.
Thanks for this question. This was it it seems. Still I can't see any problem and am not able to find the reason, but this now seems to be out of tors scope.
For now it is an IPv4 only Exit, better than nothing. 7
Anyone here who has an idea why Ubuntu with netplan suddenly refuses IPv6 connection, while internally a Ping6 to the servers IPv6 still works, please let me know your idea!
Very thankful for any help. yl _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hello AceOfSpadez79
On 11/05/2020 16:53, AceOfSpadez79 wrote:
Not sure what your issue with Ubuntu is, I'm running 20.04 and have no issues with inbound/outbound IPV4/6 connections. It kind of seems to me that the Tor relays just love to nitpick. While I'm here though I do have one question for you lads and laddettes.
It is not a Tor issue I think and it might not be a Ubuntu issue as well, but you know the game... I have to convince the support of the hosting company, at the moment I am not able to do so.
I setup a service to notify me by email whem the IPv6 connectivity fails, it is just a PING6, but it'll do the job.
Then when this happens I will check my system logs.
Regards yl
tor-relays@lists.torproject.org
-
AceOfSpadez79 -
I -
Roger Dingledine -
teor -
yl -
ylms