Impossibile aumentare il limite di file aperti oltre il 4096 (Ubuntu)


34

Sono su Ubuntu 17.04. Cercando di aumentare il limite di file aperti e nessuna delle istruzioni che ho trovato online funziona. Posso andare fino al 4096, ma non posso andare oltre.

$ ulimit -n
1024
$ ulimit -n 4096
$ ulimit -n
4096

Che funzioni. Questo non:

$ ulimit -n 4097
bash: ulimit: open files: cannot modify limit: Operation not permitted

Sembra essere a causa del limite rigido:

$ ulimit -Hn
4096

Ho provato ad aggiungere queste righe a /etc/security/limits.conf:

*                hard    nofile          65535
*                soft    nofile          65535
root             soft    nofile          65535
root             hard    nofile          65535

Inoltre ha aggiunto questa riga a /etc/pam.d/common-session e /etc/pam.d/common-session-noninteractive:

session required pam_limits.so

Da allora, ho riavviato il mio computer. Le modifiche a limits.conf non sembrano influenzare nulla. Il limite rigido è ancora bloccato a 4096, impedendomi di andare oltre. Come faccio ad aumentare il mio limite di file aperti?


Ecco alcune informazioni di configurazione aggiuntive:

$ cat /proc/sys/fs/file-max 
1624668

Risposte:


56

OK, finalmente l'ho capito. I limiti che stavo impostando in /etc/security/limits.conf venivano applicati, ma non venivano applicati all'accesso grafico. Questo può essere verificato in questo modo da una finestra del terminale:

$ ulimit -n
4096
$ su mkasberg
Password:
$ ulimit -n
65535

Altre ricerche mi hanno portato a questa segnalazione di bug , che mi ha indicato nella giusta direzione. Per modificare il limite utilizzato dalla shell di accesso, è necessario aggiungere la seguente riga in /etc/systemd/user.conf:

DefaultLimitNOFILE=65535

Tale modifica funziona, ma influisce solo sul limite morbido. (Lasciandoci limitati a un limite rigido di 4096 ancora.) Per influire anche sul limite rigido, dobbiamo modificare /etc/systemd/system.conf con la stessa modifica.

Le modifiche che ho apportato in /etc/pam.d non erano necessarie. Almeno su Ubuntu, questo sta già funzionando. Inoltre, non era necessario modificare le impostazioni per roote *in limits.conf. Modificare i limiti per mkasbergera sufficiente, almeno per il mio caso d'uso.


In sintesi

Se si desidera aumentare il limite indicato da ulimit -n, è necessario:

  • Modifica /etc/systemd/user.conf e /etc/systemd/system.conf con la seguente riga (si occupa dell'accesso grafico):

    DefaultLimitNOFILE=65535
    
  • Modifica /etc/security/limits.conf con le seguenti righe (si occupa dell'accesso non GUI):

    mkasberg hard nofile 65535
    mkasberg soft nofile 65535
    
  • Riavvia il computer per rendere effettive le modifiche.


2
DefaultLimitNOFILE=65535ha fatto il trucco. Ma perché /etc/security/limits.conf non funziona?
Suvitruf dice di reintegrare Monica il

6
L'accesso alla GUI utilizza systemd, che apparentemente ha la propria configurazione ( /etc/systemd/system.conf) che è indipendente dalla normale configurazione per le sessioni del terminale ( /etc/security/limits.conf). Non so abbastanza su systemd per sapere perché è stato implementato in questo modo.
mkasberg,

1
@Suvitruf perché è ignorato in un sistema systemd . Sto postando una risposta.
Marc

1
Voglio solo sottolineare che i limiti per l' rootutente non possono essere specificati da *o specificatori di gruppo. rootletterale deve essere specificato esplicitamente.
Petr Javorik,

2
Questo funziona per me, dopo un riavvio .
Shihe Zhang,

14

Non è necessario modificare nulla nel /etc/security/limits.conffile, viene ignorato se si utilizza systemd.

(riproduzione di una risposta modificata a un'altra domanda sulla rete ...)

Un'alternativa per coloro che preferiscono non modificare i valori predefiniti /etc/systemd/system.confe i /etc/systemd/user/conffile:

  1. crea un nuovo file /etc/systemd/system.conf.d/limits.confcon questi contenuti:

    [Manager]
    DefaultLimitNOFILE=65535
    
  2. eseguire systemctl daemon-reexeccome root

  3. disconnettersi e accedere nuovamente

  4. controlla il tuo nuovo limite con ulimit -n.

Fare riferimento alla systemd-system.confpagina man per i dettagli.


Sul mio sistema Ubuntu 18.10 il file in questione è all'indirizzo /etc/systemd/system.conf. Apportare la modifica lì sembra aver fatto il trucco, grazie.
Stephen Kennedy,

1
La disconnessione per me non ha funzionato (Ubuntu 18.04) ma il riavvio ha funzionato. Soluzione molto elegante, grazie.
stann1

0

Usando Ubuntu 17.04 ho ottenuto il limite rigido descritto:

user@paresh.com:~$ ulimit -Hn
4096

Potrei abbassarlo usando ulimit, ma non aumentarlo, proprio come la domanda lo descrive. ulimitil manuale descrive:

solo root può aumentare il limite massimo.

Quindi ho cercato di impostare un limite superiore in /etc/security/limits.confquesto modo:

user hard nofile 9999

e un nuovo login come ssh localhost -l usermi ha dato il nuovo limite:

user@paresh.com:~$ ulimit -Hn
9999

Spero che questo funzioni anche per te.


0
  1. modifica /etc/systemd/system/sonar.service

  2. aggiungi queste due righe in Servizio

[Servizio]

LimitMEMLOCK = infinito

LimitNOFILE = 65535

  1. systemctl daemon-reload
  2. ecoscandaglio riavvio del sistema

questo funziona per me.


0

TL; DR Ho sentito il bisogno di concentrare le risposte, quindi sono più facili da trovare. Mi ci sono voluti anni per mettere insieme tutti i pezzi per farlo funzionare correttamente ...

Ci sono 2 posizioni da considerare.

  1. Sessione della GUI

    $ grep DefaultLimitNOFILE /etc/systemd/system.conf
    DefaultLimitNOFILE=65535
    

    o meglio qui:

    $ grep NOFILE /etc/systemd/system.conf.d/limits.conf
    DefaultLimitNOFILE=65535
    
  2. ambiente shell

    $ grep nofile /etc/security/limits.conf
    user soft nofile 65535
    user hard nofile 65535`
    

    o meglio qui:

    $ grep nofile /etc/security/limits.d/user.conf
    user soft nofile 65535
    user hard nofile 65535
    
  3. Dopo aver modificato le impostazioni nei file precedenti, riavviare e quindi controllare i limiti con: ulimit -n -Hn -Sn

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.