Opened 9 years ago

Closed 9 years ago

Last modified 8 years ago

#5112 closed defect (fixed)

Tor fails to bind to socket, SOCK_CLOEXEC unsupported on 2.6.18 kernel

Reported by: fob Owned by: nickm
Priority: Medium Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version: Tor:
Severity: Keywords: tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


When I start Tor I get this error.

Feb 13 21:06:55.032 [notice] Tor v0.2.3.12-alpha (git-800942b4176ca31c) running on Linux i686.
Feb 13 21:06:55.032 [notice] Tor can't help you if you use it wrong! Learn how to be safe at
Feb 13 21:06:55.032 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Feb 13 21:06:55.032 [warn] This copy of Tor was compiled to run in a non-anonymous mode. It will provide NO ANONYMITY.
Feb 13 21:06:55.032 [notice] Read configuration file "/usr/local/etc/tor/torrc".
Feb 13 21:06:55.036 [notice] Wow! I detected that you have 24 CPUs. I will not autodetect any more than 16, though. If you want to configure more, set NumCPUs in your torrc
Feb 13 21:06:55.036 [notice] Initialized libevent version 2.0.10-stable using method epoll (with changelist). Good.
Feb 13 21:06:55.036 [notice] Opening Socks listener on
Feb 13 21:06:55.036 [warn] Socket creation failed: Invalid argument
Feb 13 21:06:55.036 [warn] Failed to parse/validate config: Failed to bind one of the listener ports.
Feb 13 21:06:55.036 [err] Reading config failed--see warnings above.

Running Tor in strace shows the error.
[pid 6100] socket(PF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_TCP) = -1 EINVAL (Invalid argument)

From googling the problem appears to be the use of SOCK_CLOEXEC which is not supported by my kernel.
Linux kernel 2.6.18 is still used by many distros with active support, such as RHEL/CentOS 5, gentoo.

My specific case is I am trying to get it working on an OpenVZ gentoo vps using kernel vz22915 2.6.18-028stab056-aufs-teak-rin1.

Tor works fine.

Child Tickets

Change History (7)

comment:1 Changed 9 years ago by nickm

Milestone: Tor: 0.2.3.x-final
Owner: set to nickm
Status: newaccepted

As an aside, you're aware of this part, right:

Feb 13 21:06:55.032 [warn] This copy of Tor was compiled to run in a non-anonymous mode. It will provide NO ANONYMITY.


I think most people haven't run into this, because they don't build their Tor with one set of kernel headers (supporting SOCK_CLOEXEC), and then try to run it on a different kernel. As a workaround, are you able to compile with a set of headers that don't have SOCK_CLOEXEC?

In any case, we should fix this for 0.2.3.x-final.

comment:2 Changed 9 years ago by fob

Yes I am aware its compiled in tor2web mode, thats why I was trying the alpha version.

I never considered it was because of the kernel headers.
Yes it works when compiled with the correct headers.

I originally compiled it on a gentoo openvz vps, but the vps host is likely not running the gentoo kernel, but probably RHEL5 openvz kernel.
I think this kind of configuration is normal for vps providers, the other apps i compiled on the server didn't give any issues.

Thanks for fixing it in the final.

comment:3 Changed 9 years ago by nickm

Status: acceptedneeds_review

There's a likely fix for this in branch "bug5112" of my public repository. Needs testing and review.

From the commit message:

    Since, we've supported the Linux extensions to socket(),
    open(), socketpair(), and accept() that enable us to create an fd and
    make it close-on-exec with a single syscall.  This not only saves us a
    syscall (big deal), but makes us less vulnerable to race conditions
    where we open a socket and then exec before we can make it
    But these extensions are not supported on all Linuxes: They were added
    between 2.6.23 or so and 2.6.28 or so.  If you were to build your Tor
    against a recent Linux's kernel headers, and then run it with a older
    kernel, you would find yourselve unable to open sockets.  Ouch!
    The solution here is that, when one of these syscalls fails with
    EINVAL, we should try again in the portable way.  This adds an extra
    syscall in the case where we built with new headers and are running
    with old ones, but it will at least allow Tor to work.

comment:4 Changed 9 years ago by nickm

Ugh. Apparently I fixed this again in branch cloexec_fallback. We should see which one is better and review and merge that.

FWIW, bug5112 appears to have a better commit message.

comment:5 Changed 9 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

This still looks okay to me. Merging the "bug5112" version, which is a bit better documented.

comment:6 Changed 8 years ago by nickm

Keywords: tor-client added

comment:7 Changed 8 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.