[tor-relays] Debian Stretch (Raspbian): Tor daemon fails to complete launching procedure, endless cycling.

[teor]

> On 28 Dec 2017, at 21:39, Ralph Wetzel <theonionbox at gmx.com> wrote:
> 
> Hi there!
> I took the advantage of some family time to update my Tor Relay to the latest RPi Raspbian release (based on Debian Stretch).
> The Pi does nothing else than running a Tor node, so no 'customized' configuration or settings are necessary / applied at all.
> Even after installation of the latest tor package (as usual: apt-get install tor) everything looked fine... until I encountered, that the tor daemon failed to launch automatically.
> 
> Doing some investigation, I found this [0] info reporting an issue with the systemd setup of Tor on latest Debian / Unbutu and followed the proposed procedure: After renaming 'tor.service' and a 'sudo systemctl daemon-reload' the system then tried to launch the 'tor at default' service - named being 'the correct one'. So far so fine.

This works fine without modification on my Debian and Ubuntu boxes.

If I want to see the status of individual tor instances, I use:

systemctl status tor@(instance)

If I want to see the status of all my tor instances, I use:

systemctl status tor@*

If I want to do something to all my tor instances, I use:

systemctl (action) tor

This is not related to your other issue.

> The BIG YET is, that the daemon now fails to finish it's starting sequence. More precisely, a minute (or less) after bootstrapping reaches 100%, the daemon receives (out of nothing!) an interrupt - and the cycle restarts:

The tor daemon should notify systemd when it finishes launching.
This is so systemd knows that it hasn't hung.

So either systemd is misconfigured, or your tor is compiled without
systemd support.

If tor is compiled with systemd support, it should log one of the
following messages:

Unable to send readiness to systemd
Signaled readiness to systemd
systemd NOTIFY_SOCKET not present

I can't see any of these in your log, but it might be earlier than the
part you sent.

The last message is logged at info level.
(It's also less likely to be the issue.)
To see info level logs, add this line to your torrc:

Log info file /path/to/log/file

(I don't know where your log file is.
But it's probably at /var/log/tor/log.)

> Dec 28 11:27:03.000 [notice] Bootstrapped 100%: Done
> ...
> Dec 28 11:28:49.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now.
> Dec 28 11:29:19.000 [notice] Clean shutdown finished. Exiting.

This looks like systemd killed tor due to a notify failure.

> ...
> 
> Before, there's only the one warning that looks a bit strange - but (to my guessing) should have nothing to do with the issue encountered:
> 
> Dec 28 11:27:58.000 [warn] Permissions on directory /var/run/tor are too permissive.
> Dec 28 11:27:58.000 [warn] Before Tor can create a control socket in "/var/run/tor/control", the directory "/var/run/tor" needs to exist, and to be accessible only by the user and group account that is running Tor.  (On some Unix systems, anybody who can list a socket can connect to it, so Tor is being careful.)

See below.

> Above that, 'service tor at default status' gives a status that is different from what I've seen so far:
> 
> ● tor at default.service - Anonymizing overlay network for TCP
>    Loaded: loaded (/lib/systemd/system/tor at default.service; static; vendor preset: enabled)
>    Active: activating (start) since Thu 2017-12-28 11:23:48 CET; 32s ago
>   Process: 1078 ExecStartPre=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --verify
>   Process: 1076 ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d /var/run/tor (code=exited, status=0/SUCCESS)

This looks like your torrc and systemd unit file are out of sync.

The unit file sets /var/run/tor as group-readable.
But the torrc entry for that socket doesn't seem to have RelaxDirModeCheck
(and typically the socket itself gets GroupWritable, because that's the
point of making the directory group-readable).

>  Main PID: 1082 (tor)
>    CGroup: /system.slice/system-tor.slice/tor at default.service
>            └─1082 /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0
> 
> I used to get an 'active (running) since ...' status, whereas now it stays at 'activating (start) since ...' - which technically is correct!

Back to the notify issue.
This looks like systemd has not seen a notify from tor.

> Therefore - I need some help:
> 
> 1) Can someone confirm that the Tor systemd configuration is broken as [0] states?

No, that user's expectations don't match the actual Tor systemd config.
It works fine, when you use it right.

> 2) If 1) is confirmed, is the solution offered by [0] the right way to solve the issue?

The solution will not solve your issue.

> 3) What else shall I do? If already described somewhere, a link will be highly appreciated.

Log at info level so you know exactly what has gone wrong with systemd
notifications.

If your tor doesn't log anything about systemd when it starts, you can
install a tor that is compiled with systemd support, and it should work.

If you can't do that, you can tell systemd not to expect a notification.
You can use a systemd drop-in file with "Type=simple" in it. I don't
know of any instructions to do this, but here is the manual:

https://www.freedesktop.org/software/systemd/man/systemd.service.html#Type=

T

> [0] https://askubuntu.com/questions/882527/tor-process-will-not-start-automatically-on-ubuntu-16-04

--
Tim / teor

PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20171228/6d7a9605/attachment.sig>