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

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

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

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