Opened 2 years ago

Closed 10 months ago

#21074 closed defect (fixed)

setrlimit fails OSX Sierra

Reported by: cypherpunks Owned by: nickm
Priority: Medium Milestone: Tor: 0.2.9.x-final
Component: Core Tor/Tor Version: Tor: 0.2.6.7
Severity: Normal Keywords: OSX, Sierra, setrlimit, tbb-needs, 031-backport, review-group-29 032-backport 029-backport
Cc: gk, brade, mcs, celticninja Actual Points:
Parent ID: Points: 2
Reviewer: Sponsor:

Description

User reported on Tor Stack Exchange that Tor Browser under their Sierra install was failing.

It seems to be caused by a failed call to "setrlimit"

Dec 21 23:52:00.089 [notice] Tor 0.2.9.6-rc (git-a3e07633a45d5c16) running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
Dec 21 23:52:00.090 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 21 23:52:00.091 [notice] Read configuration file "/Applications/TorBrowser.app/Contents/Resources/TorBrowser/Tor/torrc-defaults".
Dec 21 23:52:00.092 [notice] Read configuration file "/Users/leomozoloa/Library/Application Support/TorBrowser-Data/Tor/torrc".
Dec 21 23:52:00.106 [warn] Couldn't set maximum number of file descriptors: Invalid argument
Dec 21 23:52:00.106 [warn] Failed to parse/validate config: Problem with ConnLimit value. See logs for details.
Dec 21 23:52:00.106 [err] Reading config failed--see warnings above.

Note that the user *was* using the alpha but also gets the same result using the stable 6.0.8 release.

I also noted that there have been issues with OSX and setrlimit before: https://gitweb.torproject.org/tor.git/tree/src/common/compat.c?h=release-0.2.8#n1742

      /* On some platforms, OPEN_MAX is the real limit, and getrlimit() is
       * full of nasty lies.  I'm looking at you, OSX 10.5.... */

The original stack exchange ticket can be seen here: https://tor.stackexchange.com/questions/13466/tor-unexpectedly-exited-cant-launch-tor-browser-at-all-anymore-for-no-apparent?noredirect=1#comment14480_13466

I'm willing to ask the user for more information if required and a stackexchange login with 50+ rep isn't available.

Child Tickets

TicketStatusOwnerSummaryComponent
#22797closedteormacOS should use ULIMIT_BUFFER for open filesCore Tor/Tor

Change History (42)

comment:1 Changed 2 years ago by arma

Milestone: Tor: 0.2.9.x-final

comment:2 Changed 23 months ago by arma

Do we have any OS X Sierra users who can confirm this, and/or try a patch if somebody wrote one?

It looks like this ticket ended up in 0.2.9.x rather than 0.3.0.x, which means everybody who is working on making 0.3.0 go stable will ignore it. Maybe we should move it to 0.3.0.x then? :)

See also #16274 which looks related but not the same.

comment:3 Changed 23 months ago by teor

Milestone: Tor: 0.2.9.x-finalTor: 0.3.0.x-final
Points: 2

I have a Sierra install, and so does at least one other core tor developer.

For what it's worth, I don't see this error with the default torrc in Tor Browser 6.0.8 / Tor 0.2.8.11 (git-31e7b47fbebe8caf).

Do they need to set a particular ConnLimit value to trigger it?

comment:4 Changed 23 months ago by nickm

Milestone: Tor: 0.3.0.x-finalTor: unspecified
Status: newneeds_information

comment:5 Changed 22 months ago by jabu

Receiving this error on Sierra with default torrc in Tor 0.2.9.9 / Tor Browser 6.5. Have also tried other versions of Tor Browser (6.0 & 7.0a1) which still produce the error.

The only solution is to run tor under sudo.

I don't know much about debugging tor, would be happy to provide more information with instructions.

comment:6 in reply to:  5 Changed 22 months ago by teor

Replying to jabu:

Receiving this error on Sierra with default torrc in Tor 0.2.9.9 / Tor Browser 6.5. Have also tried other versions of Tor Browser (6.0 & 7.0a1) which still produce the error.

The only solution is to run tor under sudo.

I don't know much about debugging tor, would be happy to provide more information with instructions.

Does the error happen if you start tor outside of Tor Browser:

/path/to/tor ORPort 0

It would be helpful to have info-level logs.
To log at info level, start tor like this:

/path/to/tor ORPort 0 Log "info stderr"

Or, if the error only happens in Tor Browser, add this line to the default torrc:

Log info stderr

comment:7 Changed 22 months ago by gk

Cc: gk added
Keywords: tbb-wants added

FWIW: we've had an additional user on #tor reporting this problem yesterday.

comment:8 Changed 22 months ago by gk

uname -n -S gives 8192 for them.

comment:9 Changed 22 months ago by mcs

Cc: brade mcs added

comment:10 Changed 20 months ago by loopuz

hello I have exactly the same problem and i am under OS X 10.8.5 Mountain Lions

I have tried different version of tor from 6.0.7 til the latest 6.5.1 Something changed in my configuration but i dont know what .

if i boot my macbook  from an old backup disk (from december 2016 tor 6.0.7) everything works fine... i tried to copy the same application from the backup to my actual mac (that is "org.mozilla.tor browser.plist" file , the folders "org.mozilla.tor browser" and "tor browser data" and TorBrowser.app obviously) but i still get the same error! 

if i run sudo /Applications/TorBrowser.app/TorBrowser/Tor/tor.real

i get

Apr 15 16:22:59.579 [notice] Tor v0.2.6.7 (git-ac600bec40c14864) running on Darwin with Libevent 2.0.21-stable, OpenSSL 1.0.1m and Zlib 1.2.5.
Apr 15 16:22:59.579 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 15 16:22:59.659 [notice] Configuration file "/home/ubuntu/install/etc/tor/torrc" not present, using reasonable defaults.
Apr 15 16:22:59.668 [notice] Opening Socks listener on 127.0.0.1:9050
Apr 15 16:22:59.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't.
Apr 15 16:22:59.000 [notice] Bootstrapped 0%: Starting
Apr 15 16:23:00.000 [notice] Bootstrapped 5%: Connecting to directory server
Apr 15 16:23:00.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Apr 15 16:23:00.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Apr 15 16:23:01.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Apr 15 16:23:01.000 [warn] Received http status code 404 ("Not found") from server '217.69.144.94:9001' while fetching "/tor/keys/fp/585769C78764D58426B8B52B6651A5A71137189A+80550987E1D626E3EBA5E5E75A458DE0626D088C".
Apr 15 16:23:01.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Apr 15 16:23:01.000 [notice] Bootstrapped 100%: Done

(which i dont understand as i dont understand any UNIX or networking...anyway it seems that it should work but no browser is showing...)

i am willing to help debugging if someone tell me what to do!

comment:11 Changed 20 months ago by arma

Does #18530 mean that OS X 10.8's days are numbered for Tor Browser anyway (because Firefox is dropping support)?

comment:12 in reply to:  11 ; Changed 20 months ago by gk

Replying to arma:

Does #18530 mean that OS X 10.8's days are numbered for Tor Browser anyway (because Firefox is dropping support)?

Yes. (This issue is not 10.8 related, though.)

Last edited 20 months ago by gk (previous) (diff)

comment:13 in reply to:  12 Changed 20 months ago by arma

Replying to gk:

Replying to arma:

Does #18530 mean that OS X 10.8's days are numbered for Tor Browser anyway (because Firefox is dropping support)?

Yes. (This issue is not 10.8 related, though.)

Ah ha. Sorry for the noise. It sounds like the person above on 10.8 is going to be screwed soon, but "Sierra" is 10.12 and thus still supported. Carry on.

comment:14 Changed 20 months ago by loopuz

i don't know how to read the logs, when i get the "tor unexpectedly exited"error there's a "copy tor log to clipboard" but nothing happens...

i added the line

"Log info stderr" to torrc-defaults  but then what ?

comment:15 Changed 20 months ago by NeoNapster

I can report the same problem

OSX Sierra, Darwin MacBook-Pro.local 16.5.0 Darwin Kernel Version 16.5.0: Fri Mar 3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64 x86_64

Was working fine, I have no idea this seems to have happened after I installed Ableton Live at some point although I am unable to clarify this.

Apr 30 11:17:30.787 [notice] Tor 0.3.0.5-rc (git-5eb2786600014d02) running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2k and Zlib 1.2.8.
Apr 30 11:17:30.788 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 30 11:17:30.856 [notice] Configuration file "/home/debian/install/etc/tor/torrc" not present, using reasonable defaults.
Apr 30 11:17:30.859 [warn] Couldn't set maximum number of file descriptors: Invalid argument
Apr 30 11:17:30.859 [warn] Failed to parse/validate config: Problem with ConnLimit value. See logs for details.
Apr 30 11:17:30.859 [err] Reading config failed--see warnings above.

comment:16 Changed 18 months ago by ugyballoons

Same issue here- have also just installed 32bit version of Ableton Live 9.

Tor now exits with error as above.
Using previous OS X version, however- 10.11.6

Is this still a common issue or has it been opened and filleted on another ticket?

comment:17 Changed 18 months ago by teor

Milestone: Tor: unspecifiedTor: 0.3.1.x-final
Version: Tor: 0.2.9.6-rcTor: 0.2.6.7

Thanks for letting us know this is still happening.
I made #22797 to fix a bug in this code, but it probably won't fix this issue.

We still need more information.
If you have this issue:

  • do you have Ableton Live installed?
  • what do you see when you open Terminal.app and type:
    ulimit -n -S
    ulimit -S -n 10240
    ulimit -n -S
    ulimit -n -H
    
    For example, I see:
    base:~ dev$ ulimit -n -S
    256
    base:~ dev$ ulimit -S -n 10240
    base:~ dev$ ulimit -n -S
    10240
    base:~ dev$ ulimit -n -H
    unlimited
    
  • what happens if you create another user?
    • does Tor work for that user?
    • what do you get from the Terminal commands above for that user?

This seems to be an issue with Ableton Live:

  • does tor work if you quit Ableton Live?
  • does tor work if you uninstall Ableton Live?
  • what do you get from the Terminal commands above:
    • before you have ever installed Ableton Live?
    • after you install Ableton Live?
    • after you uninstall Ableton Live?

comment:18 Changed 18 months ago by fink

Hey. Just found this thread as I have same problems on Sierra (10.12.5, Tor version 0.2.9.9) and... funny, I've just replaced Ableton Live 32-bit with 64-bit.

A few things to note:

  • with the 32-bit Live installed, tor was working just fine
  • 64-bit version is the same build number as the 32-bit one
  • I can't test ulimit before Ableton Live

Still, the current output (run as a non-root user) is the same with and w/o Ableton Live installed:

a-air:~ a$ ulimit -n -S
8192
a-air:~ a$ ulimit -S -n 10240
-bash: ulimit: open files: cannot modify limit: Invalid argument
a-air:~ a$ ulimit -n -S
8192
a-air:~ a$ ulimit -n -H
unlimited

And hence, tor still doesn't work with Live uninstalled.

Hope it helps somehow...

Last edited 18 months ago by fink (previous) (diff)

comment:19 Changed 18 months ago by fink

Running a sandboxed tor with same results:

[notice] Tor 0.3.1.3-alpha (git-dc47d936d47ffc25) running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2k, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A.

[warn] Couldn't set maximum number of file descriptors: Invalid argument
[warn] Failed to parse/validate config: Problem with ConnLimit value. See logs for details.

Last edited 18 months ago by fink (previous) (diff)

comment:20 Changed 18 months ago by fink

Status: needs_informationnew

comment:21 Changed 17 months ago by fink

Temp fix for the issue:


sudo launchctl limit maxfiles 10000 10000

Need to check if this fix is long-term.

comment:22 Changed 17 months ago by nickm

Owner: set to nickm
Status: newaccepted

comment:23 Changed 16 months ago by gk

Cc: celticninja added

#23124 is a duplicate

comment:24 Changed 15 months ago by nickm

Keywords: 031-backport added
Milestone: Tor: 0.3.1.x-finalTor: 0.3.2.x-final

comment:25 Changed 15 months ago by nickm

Resolution: fixed
Status: acceptedclosed

Okay; it looks like the underlying issue was indeed probably #22797. Please re-open if this bug appears in 0.2.9.12, 0.3.0.11, 0.3.1.7-??, 0.3.2.1-alpha, or later.

comment:26 Changed 14 months ago by cypherpunks

Nov 02 01:33:11.580 [notice] Tor 0.3.1.7 (git-6babd3d9ba9318b3) running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2k, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A.
Nov 02 01:33:11.581 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Nov 02 01:33:11.654 [notice] Configuration file "/home/debian/install/etc/tor/torrc" not present, using reasonable defaults.
Nov 02 01:33:11.658 [warn] Couldn't set maximum number of file descriptors: Invalid argument
Nov 02 01:33:11.658 [warn] Failed to parse/validate config: Problem with ConnLimit value. See logs for details.
Nov 02 01:33:11.658 [err] Reading config failed--see warnings above.

Have a user on Stack Exchange reporting this still on 0.3.1.7

Original SE report is here: https://tor.stackexchange.com/questions/16033/tor-unexpectedly-exited-this-might-be-due-to-a-bug-in-tor-itself-another-progr

comment:27 Changed 14 months ago by gk

Keywords: tbb-needs added; tbb-wants removed
Resolution: fixed
Status: closedreopened

The fix for #22797 made it into 0.3.1.7, so reopening.

comment:28 Changed 13 months ago by nickm

Status: reopenedneeds_information

Most odd. I still can't reproduce this. I wonder what the difference is between this user's Sierra and mine?

One possibility here is to simply treat setrlimit() failures as non-fatal.

comment:29 Changed 12 months ago by Dbryrtfbcbhgf

#24764 is a duplicate

Last edited 12 months ago by Dbryrtfbcbhgf (previous) (diff)

comment:30 Changed 12 months ago by teor

Status: needs_informationnew

Apparently some users encountered this issue after a 10.11.6 security update:
https://tor.stackexchange.com/questions/16033/tor-unexpectedly-exited-this-might-be-due-to-a-bug-in-tor-itself-another-progr

And raising file descriptors using sudo fixes it in some cases.

So yes, I think we should presume that some configurations cause setrlimit to fail, and change tor to make setrlimit failures non-fatal.
(I have multiple Tor Browser instances on admin and non-admin users, so it's not a simple permissions issue.)

comment:31 in reply to:  30 ; Changed 12 months ago by Dbryrtfbcbhgf

Replying to teor:

Apparently some users encountered this issue after a 10.11.6 security update:
https://tor.stackexchange.com/questions/16033/tor-unexpectedly-exited-this-might-be-due-to-a-bug-in-tor-itself-another-progr

And raising file descriptors using sudo fixes it in some cases.

So yes, I think we should presume that some configurations cause setrlimit to fail, and change tor to make setrlimit failures non-fatal.
(I have multiple Tor Browser instances on admin and non-admin users, so it's not a simple permissions issue.)

This user noticed something that may be the cause of the bug.
https://trac.torproject.org/projects/tor/ticket/24764#comment:20
https://trac.torproject.org/projects/tor/ticket/24764#comment:21

comment:32 in reply to:  31 Changed 12 months ago by teor

Replying to Dbryrtfbcbhgf:

Replying to teor:

Apparently some users encountered this issue after a 10.11.6 security update:
https://tor.stackexchange.com/questions/16033/tor-unexpectedly-exited-this-might-be-due-to-a-bug-in-tor-itself-another-progr

And raising file descriptors using sudo fixes it in some cases.

So yes, I think we should presume that some configurations cause setrlimit to fail, and change tor to make setrlimit failures non-fatal.
(I have multiple Tor Browser instances on admin and non-admin users, so it's not a simple permissions issue.)

This user noticed something that may be the cause of the bug.
https://trac.torproject.org/projects/tor/ticket/24764#comment:20
https://trac.torproject.org/projects/tor/ticket/24764#comment:21

Calling launchctl to set the file limit per-user is the wrong way for JBridgeM to make this change. It should either:

  • create a separate user and set the limit on that user, or
  • set the limit on its own process, rather than all processes run by the user.

But as far as Tor is concerned, this is something that will come up in some users' configurations, so we should make the setrlimit call non-fatal, and test using the same commands as:

https://trac.torproject.org/projects/tor/ticket/24764#comment:21

to make sure we have caught all the possible failure modes.

comment:33 Changed 12 months ago by thomasd3

I am in touch with the author of JBridgeM, I will let him know about this.

comment:34 Changed 11 months ago by nickm

Status: newaccepted

comment:35 Changed 11 months ago by nickm

Status: acceptedneeds_review

I've tried to take the minimalist approach for a patch here, and made setrlimit() failures nonfatal. See my branch bug21074_029.

comment:36 Changed 11 months ago by nickm

Keywords: review-group-29 added

comment:37 Changed 11 months ago by ahf

Status: needs_reviewmerge_ready

Patch looks good to me.

comment:38 Changed 11 months ago by nickm

Merged to master; marking for possible backport.

comment:39 Changed 11 months ago by nickm

Keywords: 032-backport 029-backport added

comment:40 Changed 11 months ago by arma

Neat. Sounds like Tor Browser will either want to take this patch on its own, or get the patch backported to whichever version of Tor it ships.

comment:41 Changed 11 months ago by nickm

This patch seems to have caused a signed/unsigned comparison warning on FreeBSD:

21:15:20 ../tor/src/common/compat.c:1750:23: error: comparison of integers of different signs: 'uint64_t' (aka 'unsigned long') and 'rlim_t' (aka 'long') [-Werror,-Wsign-compare]
21:15:20       rlim.rlim_cur = MIN(try_limit, rlim.rlim_cur);
21:15:20                       ^   ~~~~~~~~~  ~~~~~~~~~~~~~
21:15:20 /usr/include/sys/param.h:299:23: note: expanded from macro 'MIN'
21:15:20 #define MIN(a,b) (((a)<(b))?(a):(b))
21:15:20                       ^

I've added a new commit to the bug21074_029 branch to fix this, and merged the branch to master again.

comment:42 Changed 10 months ago by nickm

Milestone: Tor: 0.3.2.x-finalTor: 0.2.9.x-final
Resolution: fixed
Status: merge_readyclosed

I'm calling this issue medium-badness, low risk, and tested-enough. Backporting to 0.2.9 and forward.

Note: See TracTickets for help on using tickets.