Opened 13 months ago

Closed 13 months ago

Last modified 10 months ago

#25182 closed defect (invalid)

systemd unit file starts Tor before IPv6 address is available

Reported by: sjmurdoch Owned by:
Priority: Medium Milestone: Tor: 0.3.4.x-final
Component: Core Tor/Tor Version: Tor: 0.3.3.1-alpha
Severity: Normal Keywords: ipv6, systemd
Cc: Actual Points:
Parent ID: #24403 Points:
Reviewer: Sponsor:

Description (last modified by sjmurdoch)

On Ubuntu xenial, systemd starts Tor before the IPv6 address is available and so Tor fails to assign an IPv6 address then exits. systemd tries to restart Tor (I think three times) but even by the last time there's still no IPv6 address assigned and hence Tor fails to start.

As a work-around I copied /lib/systemd/system/tor* to /etc/systemd/system/ and added RestartSec=10 to the [Service] section of tor@default.service and tor@.service. This slows down the restart such that by the second time tor starts, there is an IPv6 address available.

See log file below.

Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.587 [notice] Tor 0.3.3.1-alpha (git-dc340725f08717e3) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma 5.1
.0alpha, and Libzstd N/A.
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Read configuration file "/etc/tor/torrc".
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.591 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Feb 08 15:06:28 ephemer tor[1313]: Configuration was valid
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Tor 0.3.3.1-alpha (git-dc340725f08717e3) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma 5.1
.0alpha, and Libzstd N/A.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Read configuration file "/etc/tor/torrc".
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Scheduler type KIST has been enabled.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening Socks listener on 127.0.0.1:9050
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening OR listener on 0.0.0.0:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening OR listener on [2001:630:212:2a8:a6bf:1ff:fe25:b961]:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [warn] Could not bind to 2001:630:212:2a8:a6bf:1ff:fe25:b961:9001: Cannot assign requested address
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening Directory listener on 0.0.0.0:9030
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed Socks listener on 127.0.0.1:9050
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed OR listener on 0.0.0.0:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed Directory listener on 0.0.0.0:9030
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [warn] Failed to parse/validate config: Failed to bind one of the listener ports.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [err] Reading config failed--see warnings above.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Main process exited, code=exited, status=1/FAILURE
-- Subject: Unit tor@default.service has failed
-- Unit tor@default.service has failed.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Unit entered failed state.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Failed with result 'exit-code'.

Child Tickets

Change History (12)

comment:1 Changed 13 months ago by cypherpunks

Do you use these packages:
https://deb.torproject.org/torproject.org/dists/tor-experimental-0.3.3.x-xenial/

They don't ship the same systemd service file as in upstream tor, so this might be the wrong component to report this.

comment:2 Changed 13 months ago by cypherpunks

another possible workaround:
net.ipv6.ip_nonlocal_bind

comment:3 in reply to:  1 Changed 13 months ago by sjmurdoch

Replying to cypherpunks:

Do you use these packages:
https://deb.torproject.org/torproject.org/dists/tor-experimental-0.3.3.x-xenial/

Yes, I did.

They don't ship the same systemd service file as in upstream tor, so this might be the wrong component to report this.

What would be the correct component? I found RPM packaging but not for Debian.

comment:4 Changed 13 months ago by teor

Resolution: invalid
Status: newclosed

I can confirm that I see the same issue with IPv6 on Debian using the standard tor packages for Debian stable.
It appears to be a race condition on my machine, mostly it works, rarely it doesn't.

Please report this issue on the Debian bug tracker: https://bugs.debian.org
(Alternately, report it on the Ubuntu bug tracker, but the issue exists upstream, and I bet Debian are more likely to fix it.)

comment:6 Changed 12 months ago by sjmurdoch

A developer commenting on the Ubuntu tracker suggests that the better fix to the issue might be to modify Tor

Could not perhaps Tor be fixed to follow the advice for developers at the end of

https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/#whatdoesthismeanformeadeveloper

such that it can be started up even if the network has not yet been allocated all addresses?

It appears the issue is that systemd doesn't have a reliable way to postpone starting a program after all the network interfaces are up.

comment:7 Changed 12 months ago by teor

The relevant cross-platform advice is:

If you write a server: listen on [::], [::1], 0.0.0.0 and 127.0.0.1 only. These pseudo-addresses are unconditionally available. If you always bind to these addresses you will have code that doesn't have to react to network changes, as all you listen on is catch-all and private addresses.

Tor already implements binding to 0.0.0.0 and dynamically determining the IPv4 address at runtime. This is the default behaviour when Tor is configured using ORPort or DirPort without an explicit address.

Tor will be able to dynamically determine its IPv6 address when IPv6 reachability checks (#6939) are implemented. This depends on IPv6 extends (#24403).

comment:8 Changed 12 months ago by teor

Keywords: ipv6 systemd added
Milestone: Tor: 0.3.4.x-final
Parent ID: #24403

comment:9 Changed 12 months ago by sjmurdoch

Description: modified (diff)

I've updated the description to note that you need to copy the unit files out of /lib/systemd/system/ to /etc/systemd/system/ because otherwise upgrading Tor will overwrite your changes.

comment:10 Changed 12 months ago by teor

You can use a systemd drop-in file, which only needs to contain the changed lines.

For example, see:
https://github.com/privcount/privcount/blob/master/dist/systemd_privcount_tor.conf

comment:11 Changed 10 months ago by teor

See also:
https://trac.torproject.org/projects/tor/ticket/25803#comment:6

For a config that depends on the network being online.
Please let us know if it works for you.

comment:12 in reply to:  11 Changed 10 months ago by sjmurdoch

Replying to teor:

See also:
https://trac.torproject.org/projects/tor/ticket/25803#comment:6

For a config that depends on the network being online.
Please let us know if it works for you.

That didn't work for me. From what I understand, network-online.target means that at least one network interface is online and since IPv4 is ready before IPv6, tor is started when only the IPv4 interface is ready.

Note: See TracTickets for help on using tickets.