Re: [tor-dev] Consensus network status fetch

[sysmanager7 <sysmanager7@xxxxxxxxxxxxxx>]

crotab -l root returns 0
crontab -l user returns 0

I am running a tor relay on Ubuntu 20.4 on a digital Ocean Droplet.

NTX is used to monitor

   00:00:05 [NOTICE] Read configuration file "/etc/tor/torrc".
 x 00:00:05 [NOTICE] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
 x 00:00:05 [NOTICE] Received reload signal (hup). Reloading config and resetting internal state.

 What happens after the signal hup is my band settings are changed from 2/4 MBs to 112/120MBs. This
 usually happens at 1/2 am so the relay operates at those settings for a solid eight hours. I am paying
 for this, when the above happens, it gets expensive! Which is why this has to stop.

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, May 14, 2021 4:47 PM, Roger Dingledine <arma@xxxxxxxxxxxxxx> wrote:

> On Fri, May 14, 2021 at 06:02:50PM +0000, sysmanager7 wrote:
>
> > Why does a network status fetch cause a signal hup and my system to reset?
> > x 00:00:07 [NOTICE] Received reload signal (hup). Reloading config and resetting internal state.
>
> It probably isn't the networkstatus fetch that did it. It's much more
> likely that something else on your system sent the HUP signal -- I would
> guess it's something that is part of your Tor package.
>
> For example, if your Tor package enables logrotation, it probably hups
> Tor after that so Tor will close the old log file and reopen a new one.
>
> So, it depends which Tor package you have. Take a look at what cron jobs
> it added and what they do.
>
> --Roger
>
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev


_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev