OFF: duvida em processos do Linux
Bom dia amigos, Tenho um servidor de banco de dados, aonde uma aplicação estava rodando um select nesse banco. Porém, essa aplicação foi fechada pelo próprio usuário e o select continou a rodar (eu via o select rodando pelo comando ps ax). Notei que esse processo, estava com a flag D, o que no man do ps, diz: D, ininterrupta sono ou Uninterruptible sleep (usually IO). Não consegui entender o que realmente isso significa. Pergunto isso, pois tenho algumas flags no kernel para matar conexões de keep_alive, e eles funcionam perfeitamente bem, porem com a flag D, não funcionam, alias foi a primeira vez que me deparei com essa flag. Alguém poderia me explicar de um maneira mais clara o que aconteceu e o que acontece qdo a flag D entra em operação? Obrigado a todos. -- [.]´s ..:: S.e.r.i.a.L ::..
OFF: duvida em processos do Linux
Bom dia amigos, Tenho um servidor de banco de dados, aonde uma aplicação estava rodando um select nesse banco. Porém, essa aplicação foi fechada pelo próprio usuário e o select continou a rodar (eu via o select rodando pelo comando ps ax). Notei que esse processo, estava com a flag D, o que no man do ps, diz: -- [.]´s ..:: S.e.r.i.a.L ::..
Re: sem som
Oi, Em 9 de abril de 2011 15:48, manoel araujo mpedro.ara...@gmail.com escreveu: instalie o debian squeeze com o kde porem nao sai nenhum, com eu devo sai dessa? Bom, seria interessante mais detalhes sobre o problema, para não ficar em 'loops' improdutíveis nessa lista. Eu já passei por esse problema há muito tempo atrás, mas quando fui ver lá nas opções da interface gráfica percebi que o volume estava no mudo(não sei o pq vinha desabilitado como padrão tb). Mas seria mais colaborativo|produtivo de ambos os lados que vc descrevesse os passos que vc seguiu. Seria interessante além da saída do 'dmesg' como o colega relatou anteriormente, vc informar qual é o seu hardware(com o comando lshw ou algo semelhante)? se usa outro sistema operacional na máquina e se apresenta o mesmo problema? qual versão do debian( geralmente no /etc/debian_version) e do kernel(uname -r) vc está usando? esse problema só deu no debian? já testou com outras distribuições usando um livecd? Já olhou com alsamixer pelo terminal? Depois dar uma pesquisada no google e relatar suas experiências aqui detalhadamente :D Sds -- | .''`. | : :' : Pee Jay - http://wiki.dcc.ufba.br/~PeeJay | `. `'` | `- Bow before me for I am root! -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=hhx4m_yrjir7nr1usyc3nylf...@mail.gmail.com
Re: OFF: duvida em processos do Linux
Em 11-04-2011 12:00, ..:: S.e.r.i.a.L ::.. escreveu: Bom dia amigos, Tenho um servidor de banco de dados, aonde uma aplicação estava rodando um select nesse banco. Porém, essa aplicação foi fechada pelo próprio usuário e o select continou a rodar (eu via o select rodando pelo comando ps ax). Notei que esse processo, estava com a flag D, o que no man do ps, diz: D, ininterrupta sono ou Uninterruptible sleep (usually IO). Não consegui entender o que realmente isso significa. Pergunto isso, pois tenho algumas flags no kernel para matar conexões de keep_alive, e eles funcionam perfeitamente bem, porem com a flag D, não funcionam, alias foi a primeira vez que me deparei com essa flag. Alguém poderia me explicar de um maneira mais clara o que aconteceu e o que acontece qdo a flag D entra em operação? Obrigado a todos. Olá! Processos com status 'D' (sono profundo), são processos que estão esperando respostas de drivers ou kernel, geralmente de escrita em compartilhamento de rede, algumas vezes em HD ou memória flash e raras vezes em sockets ou pipes (comunicação entre processos). Nesse caso, o processo dorme esperando essa resposta e se for interrompido pode causar alguma falha crítica ou corromper arquivos, por isso nenhum sinal que não seja o que ele está esperando pode acordá-lo, nem SIGTERM ou SIGKILL (kill -9). Caso mate o processo pai, ele irá para o estado de zombie, onde o pai passar ser o processo 1 (init), o qual somente morre com o desligamento do sistema, isto é, somente vai sumir quando desligar/reiniciar. O estado 'D' deveria existir, quando tudo estiver bem, por frações de segundos, onde persistindo algo está errado e o processo não foi programado para acordar depois de um tempo de espera (timeout). []'s Junior Polegato
Re: OFF: duvida em processos do Linux
boa tarde amigo, Todas as dúvida, sanadas. [.]´s Serial Em 11 de abril de 2011 14:29, Junior Polegato - Linux li...@juniorpolegato.com.br escreveu: Em 11-04-2011 12:00, ..:: S.e.r.i.a.L ::.. escreveu: Bom dia amigos, Tenho um servidor de banco de dados, aonde uma aplicação estava rodando um select nesse banco. Porém, essa aplicação foi fechada pelo próprio usuário e o select continou a rodar (eu via o select rodando pelo comando ps ax). Notei que esse processo, estava com a flag D, o que no man do ps, diz: D, ininterrupta sono ou Uninterruptible sleep (usually IO). Não consegui entender o que realmente isso significa. Pergunto isso, pois tenho algumas flags no kernel para matar conexões de keep_alive, e eles funcionam perfeitamente bem, porem com a flag D, não funcionam, alias foi a primeira vez que me deparei com essa flag. Alguém poderia me explicar de um maneira mais clara o que aconteceu e o que acontece qdo a flag D entra em operação? Obrigado a todos. Olá! Processos com status 'D' (sono profundo), são processos que estão esperando respostas de drivers ou kernel, geralmente de escrita em compartilhamento de rede, algumas vezes em HD ou memória flash e raras vezes em sockets ou pipes (comunicação entre processos). Nesse caso, o processo dorme esperando essa resposta e se for interrompido pode causar alguma falha crítica ou corromper arquivos, por isso nenhum sinal que não seja o que ele está esperando pode acordá-lo, nem SIGTERM ou SIGKILL (kill -9). Caso mate o processo pai, ele irá para o estado de zombie, onde o pai passar ser o processo 1 (init), o qual somente morre com o desligamento do sistema, isto é, somente vai sumir quando desligar/reiniciar. O estado 'D' deveria existir, quando tudo estiver bem, por frações de segundos, onde persistindo algo está errado e o processo não foi programado para acordar depois de um tempo de espera (timeout). []'s Junior Polegato -- [.]´s ..:: S.e.r.i.a.L ::..
Kde Lento para abrir Aplicativos
Boa tarde, Instalei o novo debian squeeze no meu notebook e tive muita surpresa com tanta coisa boa nessa versão! Como os drivers para a minha placa de vídeo e wireless incluídas no kernel. Meu notebook é um Amazon PC com processador turion64 x2, por isso instalei o kernelamd64. O ambiente padrão do cd que baixei era o Gnome. Removi o Gnome por completo e instalei o kde4 ( gosto pessoal, prefiro o Qt ). Depois da instalação, personalizei o sistema e continuei usando normalmente, até que há umas duas semanas atrás o kde passou a gastar muito tempo para abrir os aplicativos como o Dolphin, chromium, firefox e demais instalados, levando as vezes mais de um minuto! Estou usando esta sourcelist: http://va.mu/BlF Eu gostaria de ajuda para saber por onde eu começo a investigar o que pode estar causando esse problema. Obrigado.
Re: Squid
Gostaria de usar o proxy Squid sem precisar usar NAT, li algumas coisas sobre TPROXY, mas parece que caiu em desuso. -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Henrique Tamiosso Machado htmach...@gmail.com -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Em 10 de abril de 2011 23:41, Eden Caldas edencal...@gmail.com escreveu: http://www.hardware.com.br/livros/linux-redes/configurando-servidor-proxy-com-squid.html Em 10 de abril de 2011 23:08, Henrique Tamiosso Machado htmach...@gmail.com escreveu: Olá! Estou configurando um squid em uma rede que todos os micros possuem IP válidos, gostaria de usar o squid sem fazer NAT para bloquear o acesso a algumas coisas. Alguém saberia alguma maneira de fazer isso? -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Henrique Tamiosso Machado htmach...@gmail.com -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Palestra Técnica do CISL - Debian Squeeze
O Comitê Técnico de Implementação de Software Livre do Governo Federal convida você a participar da palestra Debian Squeeze, que será realizada dia 18 de abril de 2011. Horário: 14 às 16h Local: Auditório do Serpro Porto Alegre Transmissão: A atividade será transmitida via internet pelo serviço Assiste - Vídeo Streaming Livre do Serpro. Para acompanhar, acesse: http://assiste.serpro.gov.br/cisl/ IMPORTANTE: A partir de agora pra acessar as palestras será necessário realizar login e senha (login: cisl e senha: palestracisl) Descrição: A palestra será dividida em 2 partes, a primeira indicada para os gestores e a segunda uma apresentação técnica das características da nova versão do Debian. Solicitamos que encaminhem até o dia 15/04/2011 questões que querem ver tratadas na palestra para o e-mail andre.mach...@serpro.gov.br, mas durante a palestra também será possível encaminhar as dúvidas pelo e-mail c...@serpro.gov.br e pelo twitter @CISLGovBR. 14h às 14h 40min - Debian para tomadores de decisão e gestores. * Vantagens e diferenças de utilizar um Linux oriundo de uma organização não empresarial. * Análise competitiva do Projeto Debian e do software Debian. * O que você ganha? * O que sua organização ganha? * O que suas equipes ganham? * O que muda na negociação e relação comercial para você ou sua organização? O que fazer quanto a isso? Existem boas soluções. * Perguntas e respostas. 14h 40min às 15h 30min - Apresentação técnica da Nova versão Debian 6.x * O que sysadmins e desenvolvedores ganham com Debian? * Mudanças do kernel opcionalmente todo livre. Prós e contras. Novos procedimentos de instalação. * Mudanças nos softwares mais conhecidos no servidor. ZFS? * Novos softwares mais conhecidos. * Novos desktops. * Multi-architecture. * Mudanças no processo de desenvolvimento e release de uma distribuição cada vez maior. * Futuro: Constantly Usable Testing (Debian CUT) e suporte ao Estável por 5 anos? * Perguntas e respostas Palestrante: André Felipe Machado, Colaborador do Projeto Debian, participa do Time de Parceiros, do Time de Publicidade e do Grupo de Usuários Debian-RS. Usa Linux desde 1998 e computadores desde o cartão perfurado. Engenheiro em Eletrônica desde 1988, programou de microkernel Real Time em microcontroladores fazendo DSP até sistemas web. Implantou, administrou e otimizou redes e servidores de arquivos, aplicação, banco de dados. Blog http://www.techforce.com.br. Atualmente trabalha no Serpro. Atenciosamente, Coordenação do CISL
Re: Squid
Henrique, proxy e nat são duas coisas diferentes. Leia o artigo que te passei que terá mais esclarecimentos. Em 11 de abril de 2011 16:22, Henrique Tamiosso Machado htmach...@gmail.com escreveu: Gostaria de usar o proxy Squid sem precisar usar NAT, li algumas coisas sobre TPROXY, mas parece que caiu em desuso. -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Henrique Tamiosso Machado htmach...@gmail.com -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Em 10 de abril de 2011 23:41, Eden Caldas edencal...@gmail.com escreveu: http://www.hardware.com.br/livros/linux-redes/configurando-servidor-proxy-com-squid.html Em 10 de abril de 2011 23:08, Henrique Tamiosso Machado htmach...@gmail.com escreveu: Olá! Estou configurando um squid em uma rede que todos os micros possuem IP válidos, gostaria de usar o squid sem fazer NAT para bloquear o acesso a algumas coisas. Alguém saberia alguma maneira de fazer isso? -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Henrique Tamiosso Machado htmach...@gmail.com -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- WebRep Overall rating
Re: iptables + apache em abaixo do Firewall
Eu achei que o que ele queria fazer era justamente isso, balanceamento de carga. Se não, desconsidere minhas mensagens anteriores. Abraços 2011/4/10 Eden Cardim edencar...@gmail.com: Pedro == Pedro Eugênio Rocha pedro.eugenio.ro...@gmail.com writes: Pedro Você pode criar duas entradas no dns, por exemplo: Pedro teste IN A 10.1.1.1 Pedro teste IN A 10.1.1.2 Pedro E no firewall você direciona as conexões para teste. A cada consulta o Pedro dns vai retornar um ip diferente. Mas round-robin vai distribuir a carga e exigir que ambos os servers apache sejam idênticos (senão o usuário final vai ver dois sites arbitrariamente diferentes no mesmo hostname), se for servir dois sistemas diferentes, não pode usar round-robin. Com o apache, tendo as entradas corretas de DNS (site1.com.br e site2.com.br apontando pro mesmo IP onde fica o firewall), você pode usar uma combinação de Proxy e Virtual Hosts para servir sistemas diferentes no mesmo IP, vide http://httpd.apache.org/docs/2.0/vhosts/examples.html#proxy Então seriam 3 apaches, dois escutando em portas ou ips diferentes, e um pra fazer o proxy reverso da requisição. Algo asssim [1]: ,[ apache proxy em 192.168.111.1 ] | VirtualHost 192.168.111.1 | ProxyPreserveHost On | ProxyPass / http://192.168.111.101/ | ProxyPassReverse / http://192.168.111.101/ | ServerName site1.com.br | /VirtualHost | | VirtualHost 192.168.111.1 | ProxyPreserveHost On | ProxyPass / http://192.168.111.102/ | ProxyPassReverse / http://192.168.111.102/ | ServerName site2.com.br | /VirtualHost ` ,[ apache servindo site1.com.br no ip 192.168.111.101 ] | VirtualHost 192.168.111.101 | ServerName site1.com.br | DocumentRoot /var/lib/www/site1 | /VirtualHost ` ,[ apache servindo site2.com.br no ip 192.168.111.102 ] | VirtualHost 192.168.111.102 | ServerName site2.com.br | DocumentRoot /var/lib/www/site2 | /VirtualHost ` Esse tipo de coisa é bem melhor centralizar na mesma camada, fica mais fácil de manter. Por exemplo, pra servir um site3.com.br no mesmo apache que o site2.com.br é só acrescentar: ,[ apache servindo site3.com.br no ip 192.168.111.102 ] | VirtualHost 192.168.111.102 | ServerName site3.com.br | DocumentRoot /var/lib/www/site3 | /VirtualHost ` [1] - Não testei as configurações acima, talvez precisem de algum ajuste pra funcionar, como de praxe, YMMV. -- Eden Cardim Software Engineer edencardim.com +55 73 9986-3963 -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwppzvwb@gmail.com -- Pedro Eugênio Rocha Linux user #473848 Mestrado em Informática - UFPR Técnico Judiciário - TRE-PR -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=sb3ha-dp3aef4vfcghoeabej...@mail.gmail.com
Re: OFF: duvida em processos do Linux
Ainda não estou neste nível T_T Mas chego lá :D Att. Em 11 de abril de 2011 13:52, ..:: S.e.r.i.a.L ::.. skr...@gmail.comescreveu: boa tarde amigo, Todas as dúvida, sanadas. [.]´s Serial Em 11 de abril de 2011 14:29, Junior Polegato - Linux li...@juniorpolegato.com.br escreveu: Em 11-04-2011 12:00, ..:: S.e.r.i.a.L ::.. escreveu: Bom dia amigos, Tenho um servidor de banco de dados, aonde uma aplicação estava rodando um select nesse banco. Porém, essa aplicação foi fechada pelo próprio usuário e o select continou a rodar (eu via o select rodando pelo comando ps ax). Notei que esse processo, estava com a flag D, o que no man do ps, diz: D, ininterrupta sono ou Uninterruptible sleep (usually IO). Não consegui entender o que realmente isso significa. Pergunto isso, pois tenho algumas flags no kernel para matar conexões de keep_alive, e eles funcionam perfeitamente bem, porem com a flag D, não funcionam, alias foi a primeira vez que me deparei com essa flag. Alguém poderia me explicar de um maneira mais clara o que aconteceu e o que acontece qdo a flag D entra em operação? Obrigado a todos. Olá! Processos com status 'D' (sono profundo), são processos que estão esperando respostas de drivers ou kernel, geralmente de escrita em compartilhamento de rede, algumas vezes em HD ou memória flash e raras vezes em sockets ou pipes (comunicação entre processos). Nesse caso, o processo dorme esperando essa resposta e se for interrompido pode causar alguma falha crítica ou corromper arquivos, por isso nenhum sinal que não seja o que ele está esperando pode acordá-lo, nem SIGTERM ou SIGKILL (kill -9). Caso mate o processo pai, ele irá para o estado de zombie, onde o pai passar ser o processo 1 (init), o qual somente morre com o desligamento do sistema, isto é, somente vai sumir quando desligar/reiniciar. O estado 'D' deveria existir, quando tudo estiver bem, por frações de segundos, onde persistindo algo está errado e o processo não foi programado para acordar depois de um tempo de espera (timeout). []'s Junior Polegato -- [.]´s ..:: S.e.r.i.a.L ::..
Re: Kde Lento para abrir Aplicativos
Primeiro caso é analisar os processos... assim que iniciar o sistema, rode como root: ps -aux em um terminal, de preferência o ttyX que não seja o ambiente gráfico. Após isto use o sistema normalmente, e quando começar a ficar lento, volte ao terminal onde está rodando o programa ps -aux e veja quais aplicativos, serviços estão consumindo o maior número de memória ram e CPU. Existem vários fatores para isto estar ocorrendo, se mesmo assim você não constatar nenhuma anormalidade na CPU e memória ram, verifique por Bad Blocks e a temperatura do processador, veja se está na temperatura aceitável. É a informação que posso lhe oferecer no momento. Até mais. Saudações. Em 11 de abril de 2011 14:39, Evaldo evaldoave...@yahoo.com.br escreveu: Boa tarde, Instalei o novo debian squeeze no meu notebook e tive muita surpresa com tanta coisa boa nessa versão! Como os drivers para a minha placa de vídeo e wireless incluídas no kernel. Meu notebook é um Amazon PC com processador turion64 x2, por isso instalei o kernel amd64. O ambiente padrão do cd que baixei era o Gnome. Removi o Gnome por completo e instalei o kde4 ( gosto pessoal, prefiro o Qt ). Depois da instalação, personalizei o sistema e continuei usando normalmente, até que há umas duas semanas atrás o kde passou a gastar muito tempo para abrir os aplicativos como o Dolphin, chromium, firefox e demais instalados, levando as vezes mais de um minuto! Estou usando esta source list: http://va.mu/BlF Eu gostaria de ajuda para saber por onde eu começo a investigar o que pode estar causando esse problema. Obrigado.
