From the Tor manual:ĬonnLimit NUM The minimum number of file descriptors that must be available to the Tor process before it will start. 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). 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". 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. Predating systemd, /etc/security/nf was used (see nf(5)). For example, they can be set by systemd using, in our case, LimitNOFILE= (see systemd.exec(5)). ulimit is not the only way to set these limitations, however. One of these limitations is the number of open file descriptors a process may have at one time. ![]() Strictly speaking, ulimit(1) is a shell builtin that sets kernel-enforced limitations of the shell and all child processes of the shell. 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)Īnd 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) ![]() 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.
0 Comments
Leave a Reply. |