[SOLVED] "Address already in use." errors when trying to restart tor
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
"Address already in use." errors when trying to restart tor
I am running Tor 0.3.2.9 (git-9e8b762fcecfece6) installed via SBo on Slackware64-14.2 and today suddenly I've started to get the "Address already in use." error when I try to restart tor manually using /etc/rc.d/rc.tor restart
Code:
netstat -anp | grep 9050
Shows me the PID of a tor process. Neither kill PID nor kill -9 PID succeed with killing it, so it looks like it became unkillable.
I have even tried to rebuild and reinstall the tor package, but it didn't help.
The major change I did today just before this problem started was the kernel upgrade to 4.4.118 that fixes Spectre variant 1.
Code:
ps aux | grep tor
shows a D disk sleep (uninterruptible) state for the process
Edit1: I think I have narrowed it down a bit more. Once the system starts, tor starts fine. Restarting tor works fine. One of the things I'm using tor for is anonymizing traffic for a specific user, as described here https://trac.torproject.org/projects...raspecificuser As soon as I start a program as that user and it tries to go online - tor locks into D state, then I can't kill it. Even going to single user mode with init 1, then back to multiuser mode with init 3 (so this reloads the daemons) doesn't help. Only a full system restart.
Last edited by FlinchX; 02-28-2018 at 02:20 AM.
Reason: Added more info
Nothing happens. Tor process stays locked in same state.
I've been using tor for years and this is the first time when I notice this problem.
PS: the other tor (the one that comes bundled with tor browser) is working fine, but I assume it's just used as socks proxy by the browser.
Yeah, the tor browser only send the actual browser requests through tor, if you want other apps to be routed through it you would need the tor daemon.
Well if it's any use, i am also running Tor version 0.3.2.9 (git-9e8b762fcecfece6) here, although with kernel 4.14.21, which appears to be working. Have you tried rebuilding the tor package? Only other thing i could suggest is try to use a different kernel, and see if the problem persists.
Well if it's any use, i am also running Tor version 0.3.2.9 (git-9e8b762fcecfece6) here, although with kernel 4.14.21
It worked for me as well with all the kernels before this last update. I think 14.2 had at least 3-4 kernel updates.
Quote:
Originally Posted by coralfang
Have you tried rebuilding the tor package?
I did that, as mentioned in the first post.
Quote:
Originally Posted by coralfang
Only other thing i could suggest is try to use a different kernel, and see if the problem persists.
I'd like to wait for more feedback before getting myself involved into such a big adventure. I prefer to stick to the Slackware stock kernel, since it's been many years since I compiled my last kernel from source (and I never made kernel slackware packages compatible with stock ones). I don't even know if it's possible to just grab the kernel packages (which ones?) from -current and install them as upgrades in 14.2
The tor guys implemented some crypto/execution hardening in the latest tor versions (past 1/2 - 1 year). This might conflict with the Spectre/Meltdown kernel mitigation, but that would be also mentioned in the tor project page / forums. I cannot replicate your issue, because I quit using tor after they imposed that (Curve25519) elliptic-curves cryptography over AES, but can suggest to have a look at the tor output logs - I remember there was a launch file (DataDirectory) and the tor.log (defaults in syslog) file (available depending on where you have defined the paths in your torrc configuration file). https://www.torproject.org/docs/tor-manual.html.en
@FlinchX
but can suggest to have a look at the tor output logs[/url]
My biggest problem isn't even that tor stopped working (though that ruined a big chunk of my daily workflow), but that I can't just kill it without a full system restart. It looks like I'll need to try and replicate the problem by cloning my tor setup inside a virtual machine, at least restarting the virtual machine will be less painful and faster. Once I get time to do that, if I can replicate it, I will enable maximum verbosity for tor and see if I can get anything useful in the logs.
Quote:
Originally Posted by abga
Additionally, I hope that you are not launching tor as root
I am running tor from SBo, it suggests creating a tor user/group for this, which I did. I did not step away from the recommended way of running tor - my tor process doesn't run as root.
I saw that tor also has a newer, alpha version, perhaps I shall try that too, but like I said above, I need to try the same version, to see if I can reproduce the issue.
My biggest problem isn't even that tor stopped working (though that ruined a big chunk of my daily workflow), but that I can't just kill it without a full system restart.
I went through some of these before posting here in forum, to educate myself. Because it's literally the first time in my life when I hit this particular process behavior.
Quote:
Originally Posted by abga
- this suggest a filesystem / network storage (I/O) issue, you might want to check that too
I run logwatch and I read the mail it sends everyday, also dmesg doesn't show any filesystem I/O errors.
I have to run r8168 for my network cards as you might remember from an older forum post, since the r8169 (IIRC) kernel driver has troubles. But all other network programs work fine, none of them jams like this. Even the other tor that's bundled with tor browser works fine, it didn't fail the same way ever, not a single time.
Quote:
Originally Posted by abga
Generally, when the 9 (SIGKILL) signal doesn't work, you can always try 30 (SIGPWR) to ungracefully & instantly kill a weird behaving process.
Compared them to my very old (3-4 years) tor compilation+installation+configuration notes and found out some differences:
- I remember and also have notes about the fact that I had issues with tor writing my log file and I had to define /var/log/tor/ as the home for the tor user. Proper r/w rights for the tor user should be also set for the DataDirectory & the folder where the geoip files are to be found. I configured /var/log/tor for everything tor needs and ran a: chown -R tor:tor /var/log/tor/
- I also used these two configure parameters when building tor:
Code:
--disable-largefile
--disable-threads
I'll maybe try to replicate your setup tomorrow if I have some time to goof around with the SlackBuild, as I already have the 4.4.118 kernel in place on a system.
EDIT>
P.S. You've stated that everything was working fine before the kernel update and I forgot to mention that you should try and recompile tor (modify the SlackBuild) and add --disable-threads in the configuration section. It might help in conjunction with the recent hardening of tor & the kernel patching.
I disabled the threads because I ran tor occasionally on a slow system with limited amount of RAM.
Last edited by abga; 02-28-2018 at 09:13 PM.
Reason: -added P.S.
I was able to reproduce the exact problem in a VirtualBox VM.
This is what I did:
1. Created a new VM, picked UEFI (not sure this is relevant, but my real hardware install is UEFI).
2. Did a full Slackware64-14.2 install
3. Ran slackpkg update; slackpkg install-new; slackpkg upgrade-all, copied new kernel to EFI partition, rebooted
4. Booted into a fully patched system running kernel 4.4.118
5. Installed sbopkg, installed tor using it
6. Added user 'user' for regular work, user 'anon' that is supposed to run anonymized programs. Nothing fancy, just ran adduser, added them to all default groups.
7. Added the following rules to /etc/rc.d/rc.firewall
8. Added the following at the end of /etc/tor/torrc:
Code:
AutomapHostsOnResolve 1
DNSPort 53
TransPort 9040
9. Modified /etc/resolv.conv to contain
Code:
nameserver 127.0.0.1
10. Rebooted, it picked up my firewall rules
11. Manually started tor with '/etc/rc.d/rc.tor start' just because I didn't bother to include it into another boot script, I'll need to restart it many times anyway by hand
12. Tor starts and works. 'dig google.com' shows that name gets resolved via 127.0.0.1 that is served by tor. '/etc/rc.d/tor restart' works
13. Ran firefox as regular user 'user', set socks 5 proxy to point to localhost:9050 served by tor, Browser uses the socks proxy and an IP checking site shows another IP than mine. Tor is functional, '/etc/rc.d/tor restart' works
14. Log as anon user, run pidgin (without any proxy settings, since it's supposed to be torified transparently). Pidgin freezes. Tor shows up in D state in output of ps aux. '/etc/rc.d/tor restart' fails
Quote:
Originally Posted by abga
you should try and recompile tor (modify the SlackBuild) and add --disable-threads in the configuration section. It might help in conjunction with the recent hardening of tor & the kernel patching.
This is the next thing I'm going to do and I will report back here.
I recompiled tor with --disable-threads option, reinstalled the slackware package and did a full reboot. It didn't help. The symptoms are exactly the same: tor works fine as DNS service / SOCKS proxy but freezes as soon as I try to transparently anonymize a program through it.
- the new kernel you updated also contains the modules iptables needs to run and before moving to an older "unhardened" tor version (as suggested in one of my posts above), I'd try to rule out that tor isn't entering a loop because of some iptables related issue - more specifically, the -m owner parameter and its related xt_owner module might not work well.
Can you please try to route all internet traffic through tor and see if this setup works well: https://trac.torproject.org/projects...tionThroughTor
- this setup contains a specific rule to not route tor traffic through itself:
Code:
# Don't nat the Tor process, the loopback, or the local network
iptables -t nat -A OUTPUT -m owner --uid-owner $_tor_uid -j RETURN
iptables -t nat -A OUTPUT -o lo -j RETURN
As far as I know, vanilla Slackware comes without a firewall script and no software after a full Slackware install tries to set up its custom rules. Are these things needed in this particular situation? I am asking this for eventually learning something I didn't know rather than just for the sake of arguing. Regardless of it, I went and added these rules at the top of the firewall script. After a full VM reboot, the tor problem persists.
Quote:
Originally Posted by abga
- the new kernel you updated also contains the modules iptables needs to run and before moving to an older "unhardened" tor version (as suggested in one of my posts above), I'd try to rule out that tor isn't entering a loop because of some iptables related issue - more specifically, the -m owner parameter and its related xt_owner module might not work well.
Can you please try to route all internet traffic through tor and see if this setup works well: https://trac.torproject.org/projects...tionThroughTor
- this setup contains a specific rule to not route tor traffic through itself:
Code:
# Don't nat the Tor process, the loopback, or the local network
iptables -t nat -A OUTPUT -m owner --uid-owner $_tor_uid -j RETURN
iptables -t nat -A OUTPUT -o lo -j RETURN
As I can see, there's quite a big example firewall script. I'm afraid my firewall knowledge is not even enough to make me able to estimate how much time would I need to study it before trying to apply on my test VM. But I will be reading on this setup for sure, because I am really interested to get back tor to a fully functional state. If anybody manages to try this scenario before me, just please post some feedback here.
I got some time (a little more than planned) to replicate your scenario, detailed in post #11, and ended up with the same results.
Since you stated that everything worked fine before the 4.4.118 kernel, I fear that something related to the MeltDown&Spectre patches is conflicting with tor.
The netfilter modules look OK at the first glance, I did some additional testing on them, since I also rely heavily on iptables and feared that I might get myself in trouble if these modules are somehow broken. I'm still not ruling out that they might also be/cause an issue.
My recommendation is to make sure that the new kernel is what breaks tor, this will require a kernel downgrade and I don't really know where (or if) the previous version of the Slackware kernel is available.
Report a bug at tor and point them to this thread. You can mention it anonymously on their blog page (not really the best way) or create a ticket: https://trac.torproject.org/projects/tor/newticket
- extra: I'll "polish" my post #6 - keep it only factual about their crypto choice, just to not influence your chance of getting helped (I lost my interest in tor, nothing to gain/loose)
Tor 0.2.9.14 (git-3f9bd01bf5736ff6) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.2n and Zlib 1.2.8.
- anon user definition:
Code:
id anon
uid=1002(anon) gid=100(users) groups=100(users)
finger anon
Login: anon Name: (null)
Directory: /home/anon Shell: /bin/bash
Never logged in.
No mail.
No Plan.
AutomapHostsOnResolve 1
DNSPort 53
TransPort 9040
VirtualAddrNetwork 10.192.0.0/10
- nslookup www.google.com as user anon (tor process has apparently no issues with DNS requests):
Code:
iptables -vnL
Chain INPUT (policy DROP 1 packets, 32 bytes)
pkts bytes target prot opt in out source destination
2 136 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
33 10551 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 owner UID match 1002 tcp dpt:9040
1 60 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 owner UID match 1002 udp dpt:53
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 owner UID match 1002
1 76 ACCEPT all -- * lo 0.0.0.0/0 127.0.0.1
29 10391 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED
iptables -vnL -t nat
Chain PREROUTING (policy ACCEPT 1 packets, 32 bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 1 packets, 60 bytes)
pkts bytes target prot opt in out source destination
0 0 REDIRECT tcp -- * * 0.0.0.0/0 10.192.0.0/10 tcp flags:0x17/0x02 redir ports 9040
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 owner UID match 220
1 60 RETURN all -- * lo 0.0.0.0/0 0.0.0.0/0
0 0 RETURN all -- * * 0.0.0.0/0 127.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 10.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 172.16.0.0/12
0 0 RETURN all -- * * 0.0.0.0/0 192.168.0.0/16
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 100.64.0.0/10
0 0 RETURN all -- * * 0.0.0.0/0 169.254.0.0/16
0 0 RETURN all -- * * 0.0.0.0/0 192.0.0.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.0.2.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.88.99.0/24
0 0 RETURN all -- * * 0.0.0.0/0 198.18.0.0/15
0 0 RETURN all -- * * 0.0.0.0/0 198.51.100.0/24
0 0 RETURN all -- * * 0.0.0.0/0 203.0.113.0/24
0 0 RETURN all -- * * 0.0.0.0/0 224.0.0.0/3
0 0 REDIRECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 owner UID match 1002 tcp redir ports 9040
0 0 REDIRECT udp -- * * 0.0.0.0/0 0.0.0.0/0 owner UID match 1002 udp dpt:53 redir ports 53
Chain POSTROUTING (policy ACCEPT 1 packets, 60 bytes)
pkts bytes target prot opt in out source destination
- after running lynx www.google.com as the anon user (subsequent tor freeze - entering D state):
Code:
iptables -vnL
Chain INPUT (policy DROP 5 packets, 160 bytes)
pkts bytes target prot opt in out source destination
133 12074 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
1044 880K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 2 packets, 80 bytes)
pkts bytes target prot opt in out source destination
9 1928 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 owner UID match 1002 tcp dpt:9040
7 420 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 owner UID match 1002 udp dpt:53
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 owner UID match 1002
113 8778 ACCEPT all -- * lo 0.0.0.0/0 127.0.0.1
1063 134K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED
iptables -vnL -t nat
Chain PREROUTING (policy ACCEPT 5 packets, 160 bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 115 packets, 6623 bytes)
pkts bytes target prot opt in out source destination
0 0 REDIRECT tcp -- * * 0.0.0.0/0 10.192.0.0/10 tcp flags:0x17/0x02 redir ports 9040
3 144 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 owner UID match 220
60 3983 RETURN all -- * lo 0.0.0.0/0 0.0.0.0/0
0 0 RETURN all -- * * 0.0.0.0/0 127.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 10.0.0.0/8
18 864 RETURN all -- * * 0.0.0.0/0 172.16.0.0/12
0 0 RETURN all -- * * 0.0.0.0/0 192.168.0.0/16
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 100.64.0.0/10
0 0 RETURN all -- * * 0.0.0.0/0 169.254.0.0/16
0 0 RETURN all -- * * 0.0.0.0/0 192.0.0.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.0.2.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.88.99.0/24
0 0 RETURN all -- * * 0.0.0.0/0 198.18.0.0/15
0 0 RETURN all -- * * 0.0.0.0/0 198.51.100.0/24
0 0 RETURN all -- * * 0.0.0.0/0 203.0.113.0/24
0 0 RETURN all -- * * 0.0.0.0/0 224.0.0.0/3
1 48 REDIRECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 owner UID match 1002 tcp redir ports 9040
0 0 REDIRECT udp -- * * 0.0.0.0/0 0.0.0.0/0 owner UID match 1002 udp dpt:53 redir ports 53
Chain POSTROUTING (policy ACCEPT 116 packets, 6671 bytes)
pkts bytes target prot opt in out source destination
- strace output for the tor process. The last lines after the execution, nothing else happened after the DNS and the lynx www.google.com anon user requests:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.