Tor.service fail to start on Silverblue (F39)

Ask Fedora
, ,
1

Hi everyone, I have this issue with the Tor service:

[~]$ sudo systemctl status tor.service
× tor.service - Anonymizing overlay network for TCP
     Loaded: loaded (/usr/lib/systemd/system/tor.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: failed (Result: exit-code) since Mon 2023-12-11 10:37:27 CET; 2min 41s ago
    Process: 24605 ExecStartPre=/usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc --verify-config (code=exited, status=1/FAILURE)
        CPU: 35ms

dic 11 10:37:27 matebook systemd[1]: tor.service: Scheduled restart job, restart counter is at 5.
dic 11 10:37:27 matebook systemd[1]: tor.service: Start request repeated too quickly.
dic 11 10:37:27 matebook systemd[1]: tor.service: Failed with result 'exit-code'.
dic 11 10:37:27 matebook systemd[1]: Failed to start tor.service - Anonymizing overlay network for TCP.

Fails also when trying to restart with: sudo systemctl restart tor.service

If I start it manually from the terminal using sudo -u toranon tor, it starts properly.

Does anyone else have this issue?

1 Like
3

Hi, here’s the output of the commands:

[~]$ grep -v -e "^#" -e "^$" /etc/tor/torrc
ControlSocket /run/tor/control
ControlSocketsGroupWritable 1
CookieAuthentication 1
CookieAuthFile /run/tor/control.authcookie
CookieAuthFileGroupReadable 1

[~]$ journalctl --no-pager -b -u tor.service
dic 11 09:20:57 matebook systemd[1]: Starting tor.service - Anonymizing overlay network for TCP...
dic 11 09:20:57 matebook tor[3017]: Dec 11 09:20:57.093 [notice] Tor 0.4.8.9 running on Linux with Libevent 2.1.12-stable, OpenSSL 3.1.1, Zlib 1.2.13, Liblzma 5.4.4, Libzstd 1.5.5 and Glibc 2.38 as libc.
dic 11 09:20:57 matebook tor[3017]: Dec 11 09:20:57.093 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/
dic 11 09:20:57 matebook tor[3017]: Dec 11 09:20:57.093 [notice] Read configuration file "/usr/share/tor/defaults-torrc".
dic 11 09:20:57 matebook tor[3017]: Dec 11 09:20:57.093 [notice] Read configuration file "/etc/tor/torrc".
dic 11 09:20:57 matebook tor[3017]: Dec 11 09:20:57.097 [warn] Directory /var/lib/tor/keys cannot be read: Permission denied
dic 11 09:20:57 matebook tor[3017]: Dec 11 09:20:57.097 [warn] Failed to parse/validate config: Couldn't access private data directory "/var/lib/tor/keys"
dic 11 09:20:57 matebook tor[3017]: Dec 11 09:20:57.097 [err] Reading config failed--see warnings above.
dic 11 09:20:57 matebook systemd[1]: tor.service: Control process exited, code=exited, status=1/FAILURE
dic 11 09:20:57 matebook systemd[1]: tor.service: Failed with result 'exit-code'.
dic 11 09:20:57 matebook systemd[1]: Failed to start tor.service - Anonymizing overlay network for TCP.

-- repeated --


[~]$ journalctl --no-pager -b -g avc:
-- No entries --
4

Yes. I am having the same issue in Silverblue. Could be related to SELinux. I have raised a bug here

https://bugzilla.redhat.com/show_bug.cgi?id=2252618

DO NOT RUN TOR AS ROOT. Correct workaround is to change ownership of /var/lib/tor back to toranon user.

> cd /var/lib/tor/
> chown toranon:toranon *
> systemctl start tor
2 Likes
5

Thanks, I fixed.

The issue is that the UID doesn’t match the one in passwd (getent passwd)

toranon:x:972:968:Tor anonymizing user:/var/lib/tor:/sbin/nologin

[~]$ sudo ls -lhR /var/lib/tor
/var/lib/tor:
totale 34M
-rw-------. 1 968 toranon  18K 24 nov 09.16 cached-certs
-rw-------. 1 968 toranon 2,7M 30 nov 12.11 cached-microdesc-consensus
-rw-------. 1 968 toranon  22M 24 nov 09.46 cached-microdescs
-rw-------. 1 968 toranon 8,9M 30 nov 09.33 cached-microdescs.new
drwx------. 1 968 toranon    0 20 apr  2023 keys
-rw-------. 1 968 toranon    0 30 nov 09.31 lock
-rw-------. 1 968 toranon  18K  2 dic 21.52 state

I changed permission to entire folder, because the group was root.

sudo chown -R toranon:toranon /var/lib/tor

Now it works fine. :grin:

6

This looks a lot like Move away from nss-altfiles (was: Messed up permissions in /var) · Issue #362 · fedora-silverblue/issue-tracker · GitHub, which has a workaround in Move away from nss-altfiles (was: Messed up permissions in /var) · Issue #362 · fedora-silverblue/issue-tracker · GitHub.

7

Somehow it appears that the uid and gid were switched between the user creation in /etc/passwd and maybe that in /etc/group as well as that used for the directory ownership. Installing the package seems to have had a problem.

Glad you found it and the workaround.

8

Issue persists on Silverblue F40

1 Like
9

Can confirm, struggle with it for 3 days already. I don’t want to permanently disable SELinux. It’s not secure. But I also can’t create toranon user - SystemD Login manager service prevents me from doing that.

10 
sudo chown -R toranon:toranon /var/lib/tor

Doesn’t work on Fedora Silverblue 40.

  1. toranon user is missing at all
  2. toranon user can’t be created - SystemD prevents it
11

You should definitely be able to create users, nothing in systemd should prevent that. Please paste the commands you ran and the errors you got.

12 
$> sudo useradd -m -s /bin/bash toranon
useradd: lock /etc/group.lock already used by PID 4
useradd: cannot lock /etc/group; try again later.
$> ps 4
    PID TTY      STAT   TIME COMMAND
      4 ?        I<     0:00 [kworker/R-rcu_g]
$> sudo lsof /etc/group.lock
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc
      Output information may be incomplete.
13

I had those files (/etc/passwd.lock & /etc/group.lock) on my system but running the commands removed them.

You should be able to remove them manually and try again.

I wonder where they came from.

14

This issue solved itself somehow. And it was very strange. The only thing I did was removing custom GTK theme config from several places (& rebooting):

  • gsettings set org.gnome.desktop.interface gtk-theme 'Adwaita'
  • sed -i -r -e 's/^(gtk-theme[=])(.[^A][^d][^w][^a][^i][^t][^a].)/#\1\2/' /etc/dconf/db/local.d/99-gnome-shell-theme && echo "gtk-theme='Adwaita'" >> /etc/dconf/db/local.d/99-gnome-shell-theme && dconf update
  • flatpak override --user --env=GTK_THEME=Adwaita:dark
  • sed -i -r -e 's/^(export GTK_THEME[=])/#\1/' /etc/bashrc

The theme I’ve installed was causing syntax errors & app crashes when running gnome-software. So probably it was somehow messing with some daemons & services?

But I really wanna use a custom GTK theme AND Tor service, tbh…

1 Like
15

That does not indicate a self-fixed issue.
Your changes apparently removed the interference.

It is known and to be expected that there are times where custom software may interfere with either the OS, the desktop, or other software and it is up to the user to identify what changes might have triggered the problems. If nothing custom is installed then it is on fedora to fix it, but in your case you seem to be using 2 non-fedora packages that did not play well together in the same sandbox. Tor and the custom theme.

1 Like
16

But it’s very strange that tor and a custom theme even interfere with each other.

17

The issue has returned. IDK which layer causes it. So this is still happening on Fedora Silverblue 40. systemd-oom takes ownership of /var/lib/tor & /var/log/tor for some reason. Can be (temporarily?) solved by running this:

sudo chown -R toranon:toranon /var/lib/tor
sudo chown -R toranon:toranon /var/log/tor