Eu tenho um serviço que está vazando descritores de arquivo. É gerenciado via systemd. Existe uma maneira de reiniciar esse serviço quando ele atinge um número específico de descritores de arquivo. Quaisquer indicações serão realmente úteis.
Ontem, ao depurar em um cluster hadoop, notei algo estranho
# netstat -taupen | grep 54310
tcp 0 0 10.0.12.209:54310 10.0.12.209:54310 TIME_WAIT
Você pode notar que o ip:porta de origem é igual ao ip:porta de destino. Como isso é possível. Alguém pode me explicar como as coisas estão funcionando na camada tcp para que essa conexão funcione?
Estou servindo um diretório com conteúdo estático, digamos
|-index.html
|--a
| |-index.html
|--b
|-index.html
Quando eu acesso http://localhost/a - atualmente ele recebe um redirecionamento permanente para http://localhost/a/ que serve o http://localhost/a/index.html .
Eu gostaria de ter o mesmo comportamento sem a url do navegador mudar de http://localhost/a para http://localhost/a/ .
Estou percebendo um erro de handshake SSL quando estou usando open-urio módulo ruby em Debian:Squeeze, mas está funcionando bem em Debian:Wheezy e Debian:Jessie
Aqui está o que estou percebendo:
Debian SqueezeName
root@0fdf024c8c42:/# cat /etc/issue
Debian GNU/Linux 6.0 \n \l
root@0fdf024c8c42:/# irb
irb(main):001:0> require 'open-uri'
=> true
irb(main):002:0> open("https://www.openssl.org")
OpenSSL::SSL::SSLError: SSL_connect SYSCALL returned=5 errno=0 state=SSLv2/v3 read server hello A
from /usr/lib/ruby/1.9.1/net/http.rb:799:in `connect'
from /usr/lib/ruby/1.9.1/net/http.rb:799:in `block in connect'
from /usr/lib/ruby/1.9.1/timeout.rb:54:in `timeout'
from /usr/lib/ruby/1.9.1/timeout.rb:99:in `timeout'
from /usr/lib/ruby/1.9.1/net/http.rb:799:in `connect'
from /usr/lib/ruby/1.9.1/net/http.rb:755:in `do_start'
from /usr/lib/ruby/1.9.1/net/http.rb:744:in `start'
from /usr/lib/ruby/1.9.1/open-uri.rb:306:in `open_http'
from /usr/lib/ruby/1.9.1/open-uri.rb:775:in `buffer_open'
from /usr/lib/ruby/1.9.1/open-uri.rb:203:in `block in open_loop'
from /usr/lib/ruby/1.9.1/open-uri.rb:201:in `catch'
from /usr/lib/ruby/1.9.1/open-uri.rb:201:in `open_loop'
from /usr/lib/ruby/1.9.1/open-uri.rb:146:in `open_uri'
from /usr/lib/ruby/1.9.1/open-uri.rb:677:in `open'
from /usr/lib/ruby/1.9.1/open-uri.rb:33:in `open'
from (irb):2
from /usr/bin/irb:12:in `<main>'irb(main):003:0>
Debian WheezyName
root@d6d7e1af56d0:/# cat /etc/issue
Debian GNU/Linux 7 \n \l
root@d6d7e1af56d0:/# irb
irb(main):001:0> require 'open-uri'
=> true
irb(main):002:0> open("https://www.openssl.org")
=> #<StringIO:0x000000022aaec0>
Debian JessieName
root@405c251f32df:/# cat /etc/issue
Debian GNU/Linux 8 \n \l
root@405c251f32df:/# irb2.1
irb(main):001:0> require 'open-uri'
=> true
irb(main):002:0> open("https://www.openssl.org")
=> #<StringIO:0x00000001e45b78 @base_uri=#<URI::HTTPS:0x00000001e45ec0 URL:https://www.openssl.org>, @meta={"date"=>"Wed, 26 Aug 2015 11:56:57 GMT", "server"=>"Apache/2.4.7 (Ubuntu)", "strict-transport-security"=>"max-age=31536000; includeSubDomains", "accept-ranges"=>"bytes", "vary"=>"Accept-Encoding", "content-length"=>"2456", "content-type"=>"text/html; charset=UTF-8"}, @metas={"date"=>["Wed, 26 Aug 2015 11:56:57 GMT"], "server"=>["Apache/2.4.7 (Ubuntu)"], "strict-transport-security"=>["max-age=31536000; includeSubDomains"], "accept-ranges"=>["bytes"], "vary"=>["Accept-Encoding"], "content-length"=>["2456"], "content-type"=>["text/html; charset=UTF-8"]}, @status=["200", "OK"]>
Eu sei que isso não tem nada a ver com a versão ruby porque tentei atualizar a versão ruby, mas não ajudou.
Hoje notei que encontrei o seguinte:
Como você pode ver, a RAM está quase sem metade e o uso do espaço de troca é muito alto. Com base no meu conhecimento de livros didáticos, costumava pensar que o sistema operacional Linux tenta fazer o melhor uso da RAM e, quando fica sem RAM, move algumas das páginas menos usadas da RAM para o espaço de troca.
Alguém pode me explicar se meu conhecimento teórico está incorreto e me explicar como no mundo do linux ele realmente funciona.
Eu tenho um volume ext4 com muitos arquivos dentro de um diretório específico.
Sempre que tento criar um arquivo dentro dele com um nome específico, recebo o erro "Sem espaço no dispositivo".
$ touch /data/lake/http:____images__br037__319854_366_tp.jpg
touch: cannot touch ‘/data/lake/http:____images__br037__319854_366_tp.jpg’: No space left on device
Se eu mudar pelo menos uma letra do nome do arquivo, funciona.
Aqui está o uso do disco e do inode para esse volume:
# df -h /dev/xvdf
Filesystem Size Used Avail Use% Mounted on
/dev/xvdf 985G 679G 256G 73% /data
# df -i /dev/xvdf
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/xvdf 65536000 24751661 40784339 38% /data
Também executei o fsck para garantir que não seja um problema de corrupção de disco.
# e2fsck -y /dev/xvdf
e2fsck 1.42.9 (4-Feb-2014)
/dev/xvdf: clean, 24751661/65536000 files, 182020406/262144000 blocks
Alguém pode me ajudar como posso depurá-lo ainda mais.
Hoje notei tal situação:
[[email protected] ~]#netstat -taupen | grep 54310
tcp 0 0 ::ffff:10.0.12.209:54310 ::ffff:10.0.12.209:54310 TIME_WAIT 0 0 -
Você pode notar que o soquete de origem é igual ao soquete de destino. É possível ? Alguém por favor pode explicar.
Sempre notei um IP algo "169.254.xx" na minha tabela de roteamento mesmo quando não estou conectado a nenhuma rede no meu sistema operacional Windows.
No Linux, quando listo minha tabela de roteamento.
$ ip route show
eu recebo uma entrada como
169.254.0.0/16 dev eth0 scope link metric 1000
Alguém pode me explicar o que é esse endereço IP na verdade. Seja algo como a família 127.0.0.0/8.
Edit : No ec2, cada instância pode obter metadados sobre seus próprios, fazendo solicitações HTTP para este IP.
$ curl -s http://169.254.169.254/user-data/
Então, alguém pode me dizer a quem esse endereço IP é realmente atribuído?
Possível duplicata:
É verdade que um servidor de nomes precisa responder a consultas sobre TCP?
Eu sei que o DNS usa UDP para a maioria de suas consultas, mas em que circunstâncias ele usará o TCP?