Consensus network status fetch
Why does a network status fetch cause a signal hup and my system to reset? 00:30:35 [NOTICE] While not bootstrapping, fetched this many bytes: 17796869 (server descriptor x fetch); 8622 (server descriptor upload); 2216044 (consensus network-status fetch); 148431 x (microdescriptor fetch) x 00:00:07 [NOTICE] Read configuration file "/etc/tor/torrc". x 00:00:07 [NOTICE] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". x 00:00:07 [NOTICE] Received reload signal (hup). Reloading config and resetting internal state. xlq May 13, 2021 qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk Sent with [ProtonMail](https://protonmail.com) Secure Email.
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
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@torproject.org> 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Sun, May 16, 2021 at 06:05:59PM +0000, sysmanager7 wrote:
crotab -l root returns 0 crontab -l user returns 0
Modern cron jobs don't just live in the crontab. See also your /etc/cron* directories, which is where various packages might put cron things. For example, in my case I have an /etc/cron.daily/logrotate file (placed by my logrotate package) and also I have an /etc/logrotate.d/tor file (placed by my tor package).
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.
Switching to other config values after a HUP makes me think you are configuring your Tor in some way other than editing /etc/tor/torrc. Maybe you're doing your config changes via nyx, or some other transient way, rather than by editing the torrc file? Since this is about running a relay, you also might get better help if you switch to the tor-relays@ list: https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Hope this helps, --Roger
participants (2)
-
Roger Dingledine -
sysmanager7