From ArchWiki
Jump to: navigation, search

File descriptor ulimit

What is a file descriptor ulimit? As far as I understand it, it is a file size limit on the files current open (i.e. in memory) as monitored by the Kernel. But the Tor configuration file states that it is a "custom ulimit for the maximum number of open files"? Is this a correct use of the term ulimit? ~ Filam 09:30, 30 January 2012 (EST)

And more importantly, why would you want to set a limit on the maximum number of files open by Tor? Does Tor tend to open a unusually high number of files? ~ Filam 09:33, 30 January 2012 (EST)
Strictly speaking, ulimit(1) is a shell builtin that sets kernel-enforced limitations of the shell and all child processes of the shell. One of these limitations is the number of open file descriptors a process may have at one time. ulimit is not the only way to set these limitations, however. For example, they can be set by systemd using, in our case, LimitNOFILE= (see systemd.exec(5)). Predating systemd, /etc/security/limits.conf was used (see limits.conf(5)). The underlying mechanism in any case is typically the setrlimit(2) system call, but the term ulimit is sometimes used informally to refer to these limitations regardless of how they were set.
The setrlimit system call defines RLIMIT_NOFILE as "a value one greater than the maximum file descriptor number that can be opened by this process". There is also a "maximum size of files that the process may create" called RLIMIT_FSIZE, but this is not what the article is referring to (see below).
From the Tor manual:
ConnLimit NUM
The minimum number of file descriptors that must be available to the Tor process before it will start. Tor will ask the OS for as many file descriptors as the OS will allow (you can find this by "ulimit -H -n"). If this number is less than ConnLimit, then Tor will refuse to start.
Note that Arch's Tor package comes preconfigured with LimitNOFILE=8192 in tor.service, which is higher than the default ConnLimit of 1000. This usually doesn't need to be changed unless you are running a very active relay (Tor should notify you via stderr/syslog/journalctl when it has hit its file descriptor limit).
I hope this helps. Otherwise, I'm not sure what exactly you're confused about. EscapedNull (talk) 01:04, 20 January 2015 (UTC)

Broken Link

The polipo configuration file link is broken. Gitweb returns a 404 on the file. -yungtrizzle

It works now. Look at Pickfire (talk) 03:33, 18 November 2015 (UTC)

Running a Tor server

Considering the size of Tor#Running_a_Tor_server, I would suggest moving it to a new page Tor/Running a Tor server, or check for potential duplication. -- Alad (talk) 01:58, 24 December 2014 (UTC)

I can move Tor#.2B100Mbps_Exit_Relay_configuration_example to a seperate page if you wish or we can do the cleanup. --Usprey (talk) 03:12, 24 December 2014 (UTC)
Well, Tor#Running a Tor exit node is indeed the longest and most special usecase. So it would make sense to move that to a subpage indeed. But what do you think about Alad's suggestion to move the Tor#Running a Tor server to a subpage as a whole? The three subsections it covers (bridge, middle relay and exit node) make a nice combination and might benefit from being kept together. What do you think? --Indigo (talk) 19:05, 1 January 2015 (UTC)