Last time happened at 21st till 23rd of January for 2 systems.
root@i15:~/lyrebird# lyrebird --version
lyrebird-0.0.14
root@i15:~/lyrebird# git describe
lyrebird-0.1.0-28-g2b255ef
FWIW it is not only the stop function. Even a reload is not possible. And the behavour seems to be defined but randomly occurring for a Tor relay immediately after start. Either it accepts a "kill HUP" or not for the runtime of the process.
shouldn't it be 0.1.0 ?
Realized today that one of my bridge being "reserved" since it was created 116 days ago (https://metrics.torproject.org/rs.html#details/B8FD50DB168FAB615537D48A824E408E99D64D21) is now assigned to "moat" and has "First Seen 2024-01-10 16:26:39".
I changed the obfs4 port few days ago - might that have influenced the change?
I'm still failing to match the log numbers with the prometheus metrics values:
# journalctl -u snowflake-proxy --since "5 minute ago" | grep Relayed
Nov 21 17:22:15 putzi4 proxy[241211]: 2023/11/21 17:22:15 In the last 1m0s, there were 1 completed connections. Traffic Relayed ↓ 6038 KB, ↑ 1712 KB.
Nov 21 17:23:15 putzi4 proxy[241211]: 2023/11/21 17:23:15 In the last 1m0s, there were 2 completed connections. Traffic Relayed ↓ 9014 KB, ↑ 3188 KB.
Nov 21 17:24:15 putzi4 proxy[241211]: 2023/11/21 17:24:15 In the last 1m0s, there were 1 completed connections. Traffic Relayed ↓ 14195 KB, ↑ 3500 KB.
Nov 21 17:25:15 putzi4 proxy[241211]: 2023/11/21 17:25:15 In the last 1m0s, there were 1 completed connections. Traffic Relayed ↓ 37575 KB, ↑ 5038 KB.
# curl -s localhost:9999/internal/metrics | grep ^tor.*bound_bytes_total
tor_snowflake_proxy_traffic_inbound_bytes_total 100076
tor_snowflake_proxy_traffic_outbound_bytes_total 16937
Snowflake is started via
[Service]
ExecStart=/usr/bin/proxy -metrics -summary-interval 0h1m0s
Snowflake is v2.8.0
I got the following message 2x within the last 24 hours with cec6f991:
/var/log/tor/notice2.log:Nov 14 08:17:52.000 [notice] All current guards excluded by path restriction type 2; using an additonal guard.
/var/log/tor/notice2.log:Nov 15 21:11:16.000 [notice] All current guards excluded by path restriction type 2; using an additonal guard. [3 similar message(s) suppressed in last 132840 seconds]
and the comment above src/feature/client/entrynodes.c:2172 tells that this is not expected to happen.
Gentoo hardened + openrc here too, but IMO it is not 100% related to Sandbox. A test of my 5 relays here
for i in {1..5}; do rc-service tor$i reload ; done
often show 1-2 relays which do respond, whilst the remaining to no longer accept any signal.
I learnt it in the mean while. And it works like a charm here for my small fleet of Tor relays (all public bridges running an Debian).
The logic is in this repo [1]. Mainly 3 things to configure: The Tor repository itself [2], the auto update [3] and the unattended upgrade [4]. The obfs4 port handling is a important too [5].
Are spaces here helpful?: service—must