samba preso no máximo de 1024 arquivos abertos

Question

Estou executando um servidor de arquivos samba Ubuntu 10.04 (lúcido). Eu tenho um cliente do Windows 7, que abre um grande número de arquivos ao fazer uma cópia de milhares de pequenos arquivos de uma só vez. Ele recebe o erro "Muitos arquivos abertos", e aguarda alguns segundos, e clicar em "Tentar novamente" retoma o download.

Eu encontrei uma série de referências que dizem para aumentar o número de arquivos abertos disponíveis para o Samba para resolver o problema. Eu acho que é uma ótima idéia, e estou tentando desesperadamente fazê-lo ... mas não importa o que eu faça, ele se recusa a abrir mais de 1024 arquivos, e o problema da cópia não vai embora!

Aqui está o que eu tentei:

Eu configurei ulimit -n 25000 .

Eu também configurei o /etc/security/limits.conf para:

* soft nofiles 25000
* hard nofiles 65000
root soft nofiles 25000
root hard nofiles 65000

Eu assegurei que não há nada em /etc/security/limits.d que substitua isso.

Eu verifiquei o sysctl fs.file-max = 199468 que é mais que suficiente.

Não consigo encontrar perfis de apparmor que possam estar interferindo no samba.

Eu adicionei uma sub-rotina limit nofile 25000 65000 ao /etc/init/smbd.conf

Eu configurei max open files = 50000 no smb.conf e confirmei que ele está tendo efeito através dos arquivos de log do samba:

[2011/10/28 01:30:16,  0] smbd/open.c:151(fd_open)
  Too many open files, unable to open more!  smbd's max open files = 50000
[2011/10/28 01:30:18,  0] lib/sysquotas.c:426(sys_get_quota)
  sys_path_to_bdev() failed for path [.]!
[2011/10/28 01:30:18,  0] lib/sysquotas.c:426(sys_get_quota)
  sys_path_to_bdev() failed for path [.]!
[2011/10/28 01:30:18,  0] smbd/open.c:151(fd_open)
  Too many open files, unable to open more!  smbd's max open files = 50000
[2011/10/28 01:30:19,  0] smbd/open.c:151(fd_open)
  Too many open files, unable to open more!  smbd's max open files = 50000
[2011/10/28 01:30:20,  0] smbd/open.c:151(fd_open)
  Too many open files, unable to open more!  smbd's max open files = 50000

Confirmei que o problema ocorre quando cerca de 1000 arquivos são abertos usando lsof | wc -l no disco para me fornecer uma contagem aproximada. Não importa o que eu mude, é sempre 1000, onde o botão "Tentar novamente" aparece e a cópia é interrompida. Assim que cair abaixo de 1000, você poderá clicar em tentar novamente e voltará a copiar.

Obviamente, isso é um bug no Windows 7 ou no Samba, eu não ligo para o qual, tudo o que me interessa é corrigi-lo. Por que meu Samba não abre mais de 1000 ou mais arquivos como o que estou pedindo para fazer de várias maneiras? Existe algum outro limite que eu precise mudar?

Edit: syccbean teve uma boa sugestão. Aqui estão os resultados da inserção de ulimit -a > /tmp/samba-ulimits na seção pré-script do /etc/init/smb.conf

time(seconds)        unlimited
file(blocks)         unlimited
data(kbytes)         unlimited
stack(kbytes)        10240
coredump(blocks)     0
memory(kbytes)       unlimited
locked memory(kbytes) 64
process              15969
nofiles              25000
vmemory(kbytes)      unlimited
locks                unlimited

Além disso, estou executando a versão 2: 3.4.7 ~ dfsg-1ubuntu3 do samba.

    

Answer 1

Ok, resolvi meu problema e, ao fazê-lo, entendi melhor como os ulimits funcionam, pelo menos no Ubuntu. Houve vários problemas e acho que resolvi todos eles.

Primeiro problema, e um bobo: nofiles deve ser nofile em /etc/security/limits.conf

Outra supervisão mais significativa: Embora eu tenha garantido a inclusão do pam_limits.so em /etc/pam.d/common-session , não percebi que também havia /etc/pam.d/common-session-noninteractive . O último arquivo foi o que o samba estava usando.

Corrigir esse problema parece ter corrigido o samba, que agora pode abrir quantos descritores de arquivos desejar. Cópias do Windows concluídas com sucesso. Observe também : o Samba realmente usa o ulimit do usuário apropriado, não os ulimits com os quais o processo smbd começou, nem o ulimit do root. /etc/security/limits.conf é o local para definir isso, depois de ter configurado corretamente (ambos?) /etc/pam.d/common-session-noninteractive e /etc/pam.d/samba para usar pam_limits.so

Quanto ao outro problema, onde meu usuário estava preso a 1024 hard / 1024 soft limits, isso foi uma combinação de alguns problemas. Em primeiro lugar, apesar de ter /etc/pam.d/sshd o daemon ssh não usa o PAM, a menos que você modifique /etc/ssh/sshd_config para ter "UsePAM yes". O padrão é "não" e, sem usar o PAM, o pam_limits.so (que é responsável por aplicar o limits.conf) nem entra em ação.

Em vez disso, os ulimits padrão para logins que não são do PAM parecem herdar do pid 1 (normalmente "init"). Você pode verificar esses limites padrão de pid 1 com cat /proc/1/limits . Infelizmente, até onde eu sei, esses limites são definidos como padrões no kernel. Não parece haver nenhuma maneira de modificá-los, a não ser recompilar o kernel, ou convencer o aplicativo não-PAM a usar o PAM.

Eu também só quero oferecer o conselho de que cat /proc/<anypid>/limits é uma ótima maneira de depurar os limites de qualquer processo específico com o qual você possa ter problemas. Eu gostaria de ter descoberto isso antes.

    

Answer 2

Eu estava trabalhando com o Ubuntu 14.04 lts e precisei de várias horas para perceber o seguinte:

• O samba-ad-dc é iniciado com o upstart, portanto, as configurações em /etc/security/limits.conf são irrelevantes.
• os limites são definidos com a sub-rotina no arquivo /etc/init/samba-ad-dc.conf

• teve que haver uma linha inserida com o seguinte código:

  limite nofile 16384 16384

Depois de uma reinicialização, tudo funciona bem, o ps ax informa o id do processo do samba e cat / proc / 799 / limits mostra os limites máximos do arquivo aberto do processo 799 (troca 799 com o seu ID do processo).

    

Answer 3

Talvez o script de inicialização do Samba tenha algo como ulimit -SHn 1024 nele? Veja /etc/init.d/smb ou qualquer que seja o seu script de inicialização.