Gerenciando processos no Linux
Aprender a lidar com processos é de extrema importância para um administrador de sistemas, pois ao manipula-los podemos através de sinais (comandos) fechá-los corretamente, fechá-los bruscamente, reiniciá-los e muitas outras coisas. É fato, que a tarefa mais básica no que se refere a processos é o que chamamos de “matar o processo”, fazemos isso quando uma aplicação está travada por algum motivo qualquer, assim fechamos ela na “força”, querendo ou não ela será fechada e permitirá que o utilizador continue utilizando o sistema normalmente e tente descobrir o que ocasionou o travamento. Aprenderemos neste tutorial de uma forma simples como lidar com processos.
Introdução
A partir do momento em que inicializamos qualquer sistema Linux, temos processos rodando na memória. Basicamente tudo que um sistema operacional executa é um processo, se o servidor Apache está rodando, ele é um processo, se estamos com o OpenOffice aberto é outro processo, e por aí vai.
Aprender a lidar com processos é de extrema importância para um administrador de sistemas, pois ao manipula-los podemos através de sinais (comandos) fechá-los corretamente, fechá-los bruscamente, reiniciá-los e muitas outras coisas. É fato, que a tarefa mais básica no que se refere a processos é o que chamamos de “matar o processo”, fazemos isso quando uma aplicação está travada por algum motivo qualquer, assim fechamos ela na “força”, querendo ou não ela será fechada e permitirá que o utilizador continue utilizando o sistema normalmente e tente descobrir o que ocasionou o travamento.
Aprenderemos neste tutorial de uma forma simples como lidar com processos. Lembramos apenas que este é um assunto bastante extenso e que tem algumas variações (algumas bem significativas) com relação à outros sistemas derivados do Unix.
Na Prática
Como foi falado, tudo que está sendo executado na máquina é um processo, cada processo recebe um número de identificação aleatório, este número é exclusivo para o processo em questão enquanto ele existir, isso quer dizer que se eu abro o Firefox por exemplo, o processo que o representa receberá um número no momento em que ele é criado, enquanto o Firefox não for fechado este número não será utilizado por nenhum outro processo e mesmo que o Firefox seja aberto novamente o processo dele receberá um novo número, este número é chamado de PID que é a sigla para Process ID, ou seja, identificação do processo. O PID é fornecido automaticamente pelo Kernel.
Utilizamos o PID do processo para podermos trabalhar com ele, funciona mais ou menos como um número de RG ou CPF, podemos ter duas pessoas com o mesmo nome, porém por terem uma identificação única podemos lidar com cada uma delas sem ao menos pensarmos na possibilidade de confundir, a não ser que sejam gêmeas e tenham o mesmo nome, ué isso existe? OK, viagem pura, voltemos ao assunto. Ah, já ia esquecendo, você entendeu o raciocínio da coisa né? Podemos ter processos com nomes muito parecidos no entanto cada um terá o seu número de identificação que permitirá que o administrador trabalhe com eles sem se confundir.
Para finalizarmos o parte mais chata que é a parte teórica vamos aprender mais um conceito: Todo processo é derivado de um outro processo, exceto um, que é o primeiro processo… lógico! Então este primeiro processo é um processo chamado init, quando ligamos o computador e o sistema começa a ser carregado a primeira coisa que é carregada é o Kernel, ele vai inteiramente para a memória RAM, depois disso o Kernel carrega o init que tem o PID 1 (Um), todos os outros processos do sistema são no mínimo derivados do init. Portanto, temos aqui um conceito de processo pai, ou PPID. PPID é o PID do processo que “chamou” um determinado processo, complicado? Nem tanto. Imaginemos o seguinte: Temos o apache sendo executado em nosso servidor, o apache tem portanto um PID, fora isso, só foi possível abrir o apache porque o sistema já estava sendo executado, portanto já tinha no mínimo um processo em execução, que é o init. Neste caso o apache é um processo filho do processo init. Da mesma forma se temos um ambiente desktop instalado, como o KDE, para utiliza-lo precisamos do servidor gráfico, portanto ao inicializar o sistema temos o init que abrirá o servidor gráfico que por sua vez abrirá o KDE, e através do KDE podemos abrir o K3B por exemplo. Veja abaixo uma representação disso:
(Pai do Servidor Gráfico)
Processo Init \
(Filho do init e pai do KDE)
Servidor Gráfico \
(Filho do Servidor Gráfico e Pai do K3B)
KDE \
(Filho do KDE)
Você pode usar o comando pstree para ver os processos em forma de árvore e saber quem é “pai” de quem:
Porque precisamos falar sobre isso? Basicamente para deixar claro que o que você faz em um processo pai pode interferir no processo filho, principalmente se fecharmos um processo pai, saiba que neste caso o processo filho será fechado também.
Eu falei que a história do PPID será a última coisa para fechar a parte teórica? Mas não será 
, mas não fiquem bravos, vamos pelo menos aprender um comando para continuarmos com a parte teórica, trata-se do comando ps e sua forma de utilização mais comum é utilizando os argumentos aux, como em:
- ps é o comando em si que utilizamos para listar os processos atuais. Sem parâmetro ele mostra apenas os processos da sessão atual (terminal atual).
- A letra a serve para mostrar os processos de todos os usuários e não apenas do usuário que executou o comando ps.
- A letra u indica ao ps que ele deve mostrar o nome do usuário dono do processo em questão (quem o executou).
- E por último, mas não menos importante, a letra x que diz ao ps para listar inclusive os processos da parte gráfica e de outros terminais.
Vamos pegar uma linha do resultado para analisar:
root 1 0.0 0.1 2044 988 ? Ss 19:15 0:01 /sbin/init
Podemos visualizar facilmente acima o nome do usuário dono do processo (USER) que é o root, o número de PID do processo que é 1 e o nome do processo que é /sbin/init (na verdade o cominho completo do executável, o processo em si se chama apenas init)
As outras informações não são tão comuns de se utilizar, no entanto segue uma descrição de cada uma delas:
- %CPU: Porcentagem de uso do processo pelo processo.
- %MEM: Porcentagem de uso de memória RAM pelo processo.
- VSZ e RSS: Páginação (Tamanho do processo).
- TTY: Terminal que originou o processo.
- STAT: R, S, D, Z e T
-
- R – Running (Rodando)
- S – Sleep (Esperando)
- D – Died (Morto)
- Z – Zumbie (Erro)
- T – Stopped (Parado)
-
Variações:
-
-
- < – Prioridade maior que a padrão
- N – Prioridade menor que a padrão
- T – Processo em foreground
- s – Dono da sessão (Pai)
- w – Usando recurso swap
-
- TIME: Tempo de CPU que o processo utilizou até o momento
Agora que já sabemos como visualizar os processos ativos na máquina com o comando ps, podemos aprender que todos os processos estão em uma espécie de fila, ou seja, os processos não estão sendo executados ao mesmo tempo como parece, eles só podem ser executados um de cada vez, mas quem manipula isso é o Kernel e ocorre de forma tão rápida que é imperceptível durante a utilização normal do sistema. Só conseguimos ter uma idéia visual que trata-se realmente de uma fila se utilizarmos um programa que mostra em tempo real e constantemente na tela cada um dos processos, para isso podemos usar o comando top:
leandro 9820 0.0 0.1 3932 1476 pts/0 S+ 20:48 0:00 vim teste
Na seqüência acima, nós fizemos o seguinte:
- Abrimos o vim dizendo que o nome do arquivo a ser aberto é teste.
- Executamos o ps aux e filtramos o resultado dele com o grep para retornar somente as linhas que contenham a palavra vim.
- Achamos o número de PID do vim no resultado do ps aux e enviamos um sinal 9 (SIGKILL) para ele.
- Executados novamente o ps aux para verificar se o processo ainda existe.
No exemplo acima nós matamos o vim como foi falado, caso ele estivesse travado ou não estivesse fechando por vias normais ao enviar um sinal 9 para ele, com certeza este seria fechado, em casos normais então nem se fala, como podemos constatar, matamos o processo dele mesmo sem ter nenhum problema relacionado, apenas para fins didáticos.
A utilização do vim como exemplo não foi por acaso, ele é um programa bom para demonstrar sinais, pois ele se comporta de forma esperada na maioria dos sinais que enviamos, diferente de outros programas mal escritos que não sabem lidar com “todos” os sinais e por isso apresentam comportamento estranho ao enviarmos certos tipos de sinais.
Ainda com o vim, vamos enviar um sinal 15 dessa vez pedindo para que o ele feche ao invés de fecha-lo bruscamente:
leandro 6650 0.0 0.1 3932 1432 pts/0 S+ 20:37 0:00 vim
Ficou claro a diferença entre o sinal 9 e 15? Um matará o processo e o outro fechará, respectivamente, a diferença você entende melhor ao ler o parte “Atenção” acima.
Vamos agora utilizar o sinal SIGHUP (1) que faz com que um processo releia seu arquivo de configuração caso isso seja possível, como assim se for possível? Bem, não são todos os processos que sabem ou devem lidar com todos os sinais, no caso do SIGHUP se for enviado para um processo que não saiba interpreta-lo, este será fechado ao invés de reler seu arquivo de configuração e continuar executando. Este sinal é muito útil quando o processo em questão trata-se de uma aplicação servidora de algum serviço, como um servidor web, de e-mail, proxy e etc, pois temos a possibilidade de alterar sua configuração e fazer com que ela entre em vigor sem que o serviço fique fora do ar (nem mesmo por um segundo).
Como o vim fecha ao enviamos um sinal SIGHUP vamos utilizar como exemplo o processo do squid, dessa forma:
proxy 15116 1.4 22.4 19372 17608 ? S 09:14 1:12 (squid) -D -sYC
proxy 15116 1.4 22.4 19372 17608 ? S 09:14 1:12 (squid) -D -sYC
Na seqüência acima achamos o processo do squid, identificamos o seu PID e enviamos um sinal 1 que corresponde ao SIGHUP. Por último verificamos que o processo continua existindo e com o mesmo número PID, portanto, não foi fechado e aberto novamente, pois caso isso tivesse ocorrido o número de PID seria diferente. O fato de o processo ter recebido sinal 1 e não ter renovado o seu número PID já caracteriza que o mesmo se comportou como o esperado, pois caso contrário ou o processo não existiria mais ou estaria com um novo número de identificação.
Fica difícil ilustrar o SIGHUP na prática via escrita neste curso, já que não tem foco em servidores, mas se você já configurou ou vai configurar algum tipo de servidor, provavelmente vai alterar as configurações dele e querer que elas entrem em ação, neste caso você tem duas possibilidades consideradas “normais”, uma é reiniciar o serviço como vimos no capítulo de serviços:
A outra é ao invés de reiniciar o serviço (que deixará o serviço fora do ar) , usar o parâmetro reload:
Assim o serviço não ficará fora do ar, apenas lerá o arquivo de configuração novamente em tempo real. Mas porque é que voltamos a falar de serviços se este capítulo já passou? Apenas para mostrar que ao usarmos o parâmetro reload o script do serviço irá na verdade enviar um SIGHUP para o processo correspondente a ele. Agora as coisas começam a se encaixar….
Antes de falarmos dos sinais 18 e 19 vamos facilitar as coisas já que você deve ter percebido que apesar do comando ps aux nos trazer informações valiosas, muitas vezes apenas nos interessa número de identificação de um determinado processo. Quando este for o caso, podemos substituir o ps aux pelo comando piof ou pgrep:
Como visto acima os dois funcionam da mesma forma e tem o mesmo propósito, exibir o número PID de um determinado processo ao informarmos via parâmetro o nome deste. O pidof costuma ser mais preciso no resultado, pois o pgrep em muitos casos se confunde no resultado e acabada trazendo outros processos que por um motivo ou outro também contém a string especificada via parâmetro.
Vamos ao SIGSTOP (19) e SIGCONT (18). Falaremos deles em conjunto pois um complementa a funcionalidade do outro, enquanto o SIGSTOP nos permite dar uma “pausa” em um processo, o SIGCONT faz com que possamos continuar um processo que está parado. Ao enviarmos um sinal 19 para um processo, este deixa de consumir recursos da máquina, mas não perde seu estado atual, ou seja, pode continuar de onde parou quando for da vontade do administrador.
Imagina a cena. Você tem um determinado diretório com uma quantidade absurda de arquivos, como você é uma pessoa atenta, já que tem tantos arquivos, decide fazer um backup deles para evitar problemas futuros, para isso irá utilizar o tar e compressão bzip2, deve demorar um pouco, já que são muitos arquivos, certo? Não é só o fato de demorar que pode incomodar fazer backup, muitas vezes consume uma quantidade boa de recursos da máquina, principalmente porque o acesso ao HD fica a todo vapor, tornando a máquina muitas vezes inútil enquanto o backup está ocorrendo. Dentro deste cenário, com o backup já em andamento, seu chefe te pede um determinada documento o mais rápido possível, na linguagem que estamos acostumados a ouvir, seria “Pra ontem”, para piorar a situação você não faz idéia de onde guardou o arquivo em questão e terá que procurar.
E aí? Você pára o backup para recomeçar depois e perde o que já foi feito ou espera terminar e corre o risco de ter a atenção chamada? Usando os sinais você pode simplesmente pausar o tar e continuar depois, assim enquanto ele estiver parado você terá liberdade e conforto para trabalhar com outras coisas, como procurar o arquivo e abri-lo no OpenOffice por exemplo.
É claro que o conto acima é apenas uma ilustração para podermos trabalhar em cima do assunto, a idéia é que você desenvolva o conteúdo e aplique nas suas próprias necessidades.
Simularemos um backup de toda nossa partição raiz em um arquivo que será gerado na própria partição, apenas para fins didáticos já que o correto seria gera-lo em outro HD, partição, Pen Drive, ou qualquer outra mídia removível. Em seguida iremos enviar um SIGSTOP, checar o seu estado, enviar um SIGCONT e checar seu estado novamente:
root 6835 0.6 0.1 3544 1156 pts/0 S 19:13 0:00 tar cjvf /backup.tar.bz2 /
root 6835 0.0 0.1 3544 1220 pts/0 T 19:13 0:00 tar cjvf /backup.tar.bz2 /
É bom darmos uma pausa por aqui antes de enviarmos um SIGCONT para o processo que acabamos de parar para falar que a informação mais importante neste momento é o conteúdo da coluna STAT pois ela que nos dirá o estado atual do processo, como visto anteriormente a letra S significa que o processo está em execução mas está em espera, ou seja, não está neste exato momento consumindo recursos do processador, mas pode começar a qualquer momento. A letra T por outro lado nos informa que o processo está parado, como esperávamos que estivesse realmente, afinal enviamos um SIGSTOP para ele.
Outra observação é que conforme você deve ter percebido ao paramos um processo com o sinal 19 o processo ficará em background, isso quer dizer que as informações que o tar fornece na tela não serão mais exibidas e poderemos utilizar o terminal que estava preso pelo processo do tar.
root 6835 0.0 0.1 3544 1220 pts/0 S 19:13 0:00 tar cjvf /backup.tar.bz2 /
Ao enviarmos o sinal 18 o processo volta a ser executado conforme observado na coluna STAT, mas fora isso, se voltarmos ao terminal onde o tar estava sendo executados podemos observar seu funcionamento novamente.
Por enquanto é isso, espero que tenham gostado.
fonte; http://www.guiadohardware.net/tutoriais/processos-linux/
Publicado por: tecdom em July 27th, 2008 | Categoria Informática, Linux
- Blog do gerson Junior
- Blog do Tércio Ferreira
- Frases Ilustradas
- ITVERSA Social Responsability
- Jus Acadêmico
- Trocando Livros
- Turismo Sustentável
- tecdom on Instalando drivers do XP no DELL Dimension 1000
- GLEDSON on Instalando drivers do XP no DELL Dimension 1000
- edison silv on Corel Draw X4 ? Erro 24
- Braulio Gouveia on Instalando Scanner HP F4480 (e outros scanners) no server 2003
- Chicão on Nomeando o arquivo com a data e a hora
Siga-me no twitter
Fale comigo no msn
Links Indicados
RSS Compartilhados
Categorias
Tags
Arquivo
Serviços Públicos
Comentários Recentes
Feedjit
DEIXE UM COMENTÁRIO