Como podemos visualizar os processos correntes nos sistemas operacionais Linux?

Neste cap�tulo apresentaremos o conceito de processo e muitos outros que lhe s�o aparentados. Percorreremos numerosos exemplos de uso de comandos unix diretamente ou indiretamente relacionados ao tema.

Conceitos:

• processo
• mem�ria virtual e swap
• prioridade
• background e foreground
• environment
• sinais
• shell scripts
• vetor associativo
• threads

Ferramentas:

• ps
• kill
• nohup
• nice
• at
• set
• sh
• awk

2.1. [conceito de processo] Em sistemas multitarefa (como o unix), m�ltiplas tarefas podem estar sendo realizadas simult�neamente, por exemplo a formata��o de um disquete, a impress�o de um arquivo e a edi��o de um texto. A cada uma delas corresponde um programa que a executa. Um programa em execu��o � um processo.

Num computador que possui apenas uma cpu, na verdade apenas um processo pode estar sendo executado em cada instante. O que se faz � executar um processo durante uma fra��o fixa de segundo, congel�-lo e passar a executar um outro durante essa mesma fra��o de segundo, e assim por diante. Isso cria a ilus�o de simultaneidade.

2.2. [o comando ps] Atrav�s do comando ps pode-se examinar os processos correntes. Por exemplo:

  hal:~$ ps
    PID TTY STAT  TIME COMMAND
     45 v02 S     0:00 -bash
    105 v02 R     0:00 ps

Vamos entender o que est� acontecendo: h� um processo (o shell) com o qual voc� dialoga a fim de executar comandos. Esse � o processo de n�mero 45. O comando solicitado consiste na execu��o do programa ps. Esse programa, ao ser executado, descobre que neste momento h� dois processos: ele pr�prio (de n�mero 105) e o shell.

Na verdade al�m desses dois pode haver muitos outros que o ps n�o exibe para n�o poluir a sa�da. Atrav�s das op��es a e x entretanto pode-se exibir todos os processos correntes:

  hal:~$ ps ax
    PID TTY STAT  TIME COMMAND
      1  ?  S     0:00 init [5]             
      6  ?  S     0:00 bdflush (daemon)
      7  ?  S     0:00 update (bdflush)
     25  ?  S     0:00 /usr/sbin/crond -l10
     36  ?  S     0:00 /usr/sbin/syslogd
     38  ?  S     0:00 /usr/sbin/klogd
     40  ?  S     0:00 /usr/sbin/inetd
    101 v01 S     0:00 /sbin/agetty 38400 tty1 linux
    106  ?  Z     0:00 (atrun) 
     45 v02 S     0:00 -bash
    107 v02 R     0:00 ps ax

Neste caso, todos os processos al�m do shell e o ps dizem respeito apenas � administra��o do sistema. O agetty (por exemplo) � o processo que est� controlando o login no console virtual 1. � a ele que voc� informa o seu username e password ao logar nesse console.

O n�mero de um processo � usado para identific�-lo dentre os outros, por exemplo quando � necess�rio interromper prematuramente a sua execu��o. O unix vai numerando os processos em ordem crescente, � medida em que v�o sendo criados.

Exerc�cio 2.3: reproduza os exemplos acima de uso do ps, e experimente tamb�m us�-lo com a op��o "u" (por exemplo "ps u" ou "ps aux".

Exerc�cio 2.4: invoque a man page do ps com "man ps" e leia nela o que significa o campo "STAT". Lembre-se que voc� pode localizar palavras ao ler uma man page com o comando "/" (para uma lista de comandos pressione "h").

Exerc�cio 2.5: Em geral h� um limite superior pequeno para o n�mero que um processo pode ter (por exemplo 32767). O que voc� acha que acontece quando esse limite � atingido?

Exerc�cio 2.6: Em unix, mesmo algumas opera��es extremamente simples como listar os arquivos de um diret�rio envolvem o disparo de pelo menos um novo processo. No entanto a troca do diret�rio corrente (comando "cd") n�o provoca o disparo de processo algum. Voc� saberia explicar porqu�?

2.5. [execu��o em background] Por vezes um processo pode ser de execu��o demorada. Enquanto ele n�o terminar, o shell permanecer� aguardando, e voc� tamb�m. Para evitar esse problema, pode-se disparar o processo em "background". Vejamos um exemplo. O comando abaixo ir� comprimir todos os arquivos do diret�rio corrente. Compress�o de arquivos � uma t�pica opera��o exigente em termos de cpu, por isso um comando assim pode ser demorado:

  hal:~$ gzip -9 *

Enquanto a compress�o n�o terminar, voc� n�o poder� usar o shell para disparar novos comandos. Se, por outro lado, essa compress�o for colocada em background, o shell permanecer� livre para novos comandos:

  hal:~$ gzip -9 * &

� a ocorr�ncia do caracter "&" no final do comando instrui o shell para dispar�-lo em "background".

Exerc�cio 2.6: crie um subdiret�rio, povoe ele com arquivos e use-o para disparar a compress�o em background como indicado acima. Por exemplo:

  hal:~$ cd
  hal:~$ mkdir lixo
  hal:~$ cd lixo
  hal:~$ cp /bin/* .
  hal:~$ gzip -9 * &
  hal:~$ ps u
  (... outros comandos ...)
  hal:~$ cd ; rm -rf lixo

2.7. [Prioridade] Num sistema operacional onde v�rios processos podem estar simult�neamente em execu��o, surge �s vezes o problema de ser necess�rio privilegiar ou desprivilegiar a execu��o de um processo ou um grupo de processos.

Para agilizar a execu��o de um processo urgente ou para evitar que um processo demorado atrapalhe a execu��o de outros, o sistema operacional atribui a cada processo uma prioridade, que pode ser alterada quando necess�rio.

Neste curso iremos limitar-nos ao comando "nice". Com ele, pode-se disparar um processo com baixa prioridade, o que significa que o sistema operacional ir� privilegiar a execu��o dos outros processos em detrimento a ele.

O uso t�pico do "nice" � impedir que um processo demorado atrapalhe o uso interativo do sistema pelo(s) usu�rio(s) logados nele. No exemplo que demos antes da compress�o, o disparo atrav�s do nice seria assim:

  hal:~$ nice gzip -9 * &

Exerc�cio 2.8: Leia a man page do comando renice para saber como alterar a prioridade de um processo ap�s o seu disparo.

2.9. [O que � Environment?] Environment � uma cole��o de vari�veis que servem de par�metros para os programas que o sistema executa. Uma das mais conhecidas delas, comum ao unix e ao msdos � a vari�vel PATH. Quando se solicita na linha de comandos do shell a execu��o de um programa o shell ir� procur�-lo nos diret�rios relacionados na vari�vel PATH.

Frequentemente torna-se necess�rio para o usu�rio lidar com essas vari�veis para customizar os aplicativos que utiliza, por isso conv�m ter algumas no��es precisas nesse campo.

Vejamos um exemplo simples. O comando "man" via de regra consulta a vari�vel "PAGER" para saber qual paginador � o preferido do usu�rio. O paginador padr�o costuma ser o "more", mas h� outros, como o "less" da Free Software Foundation. Ao invocar uma man page (por exemplo "man ps") voc� poder� identificar o paginador em uso atrav�s do prompt de comandos ":" t�pico do less no canto inferior esquerdo ou pela string "more" t�pica do more no mesmo canto.

Uma pessoa que prefira usar o more ir� atribuir "more" � vari�vel PAGER, enquanto uma pessoa que prefira o less ir� atribuir "less".

Uma diferen�a importante entre as vari�veis PATH e PAGER citadas � que PATH � consultada principalmente pelo shell, enquanto que PAGER � consultada por uma aplica��o (man) disparada atrav�s do shell. No msdos isso seria irrelevante porque as vari�veis de environment s�o "do sistema", pouco importando quem as est� consultando. No unix, o environment � "per-process", portanto o shell precisa ser "avisado" de que aquela vari�vel deve ser exportada para as aplica��es:

  hal:~$ set PAGER=more
  hal:~$ export PAGER

Um outro detalhe � que nesse ponto a sintaxe depende do shell em uso. O unix conta com basicamente duas fam�lias de shells, uma baseada no Bourne Shell e outra no C Shell. Num shell com sintaxe estilo C-shell os comandos anteriores teriam que ser substit�dos pelo "setenv":

  hal:~$ setenv PAGER=more

Exerc�cio 2.10: examine o valor da vari�vel PAGER. Um modo de fazer isso � executar o comando "echo $PAGER". O comando "set" executado sem argumentos exibe todas as vari�veis atualmente definidas.

Exerc�cio 2.11: atribua repetidamente "more" e "less" para a vari�vel PAGER conforme os exemplos acima executando tamb�m uma leitura de man page (por exemplo "man ps") para confirmar a troca do paginador.

Exerc�cio 2.12: examine o(s) arquivo(s) de inicializa��o do shell que voc� usa para saber quais vari�veis s�o criadas ou inicializadas neles. Esses arquivos s�o citados em geral no final da man page (se��o "FILES").

2.13 [O que � swap?] A mem�ria � um dos componentes mais caros de um computador. Ao mesmo tempo, a situa��o habitual � que possuimos menos mem�ria do que necessitamos para fazer tudo o que queremos.

Se pud�ssemos visualizar os acessos � mem�ria do computador, perceber�amos que algumas regi�es dela permanecem sem serem acessadas durante per�odos de tempo relativamente longos. Por exemplo: se voc� estiver com v�rias aplica��es disparadas mas usando apenas uma delas, as �reas de mem�ria ocupadas pelas outras n�o estar�o sendo acessadas.

Por causa disso sistemas operacionais como o unix usam o conceito de "mem�ria virtual". Cria-se um espa�o de mem�ria fict�cio bem maior do que o que realmente existe. Por exemplo: se o seu computador possui 32 megabytes de mem�ria, ele passar� a ter, digamos, 64 megabytes de "mem�ria virtual". Isso significa que a soma de toda a mem�ria requisitada por todos os processos em execu��o pode ser 64 megabytes ao inv�s de 32.

Bem... e os outros 32? ser�o alocados 32 megabytes do winchester para eles. Assim, num determinado momento, um processo pode estar apenas parcialmente residindo na mem�ria. O sistema operacional determina uma estrat�gia para escolher o que manter na mem�ria f�sica e o que manter no disco. Havendo necessidade, pode-se subitamente enviar ao disco parte do que est� na mem�ria ou vice-versa. Esse processo � chamado "swap", e a regi�o do disco alocada � chamada "�rea de swap".

Assim, se voc� permanecer algum tempo sem usar uma aplica��o, poder� acontecer que ao tentar us�-la novamente haver� um delay significativo para a sua resposta. � o sistema operacional trazendo de volta � mem�ria partes desse processo que estavam residindo em disco.

Exerc�cio 2.14: No Linux h� um comando que apresenta dados de ocupa��o da mem�ria e da �rea de swap ("free"). D� uma olhada na man page dele e experimente us�-lo.

2.14 [o comando kill] Uma m�quina rodando unix dificilmente trava, mas por vezes uma aplica��o particular pode travar. Nesse caso, n�o � necess�rio reinicializar todo o sistema, mas apenas matar a aplica��o particular que travou, e para isso usa-se o comando "kill". Processos n�o interativos (que n�o est�o amarrados a um terminal para serem encerrados com um comando "quit" ou equivalente) necessitam tamb�m do kill para terem sua execu��o abortada.

Um modo simples de testar isso � o seguinte:

  hal:~$ sh
  hal:~$ ps
    PID TTY STAT  TIME COMMAND
     45 v02 S     0:00 -bash
    308 v02 R     0:00 sh
    309 v02 R     0:00 ps

Neste momento o prompt que voc� ganhou n�o � o do shell que estava em uso (pid=45), mas o do shell rec�m-disparado (pid=308). Dele, voc� pode matar o shell rec�m-disparado voltando ao primeiro:

  hal:~$ kill -9 308

A finalidade do "-9" � assegurar que o processo ser� morto, pois, como veremos no pr�ximo par�grafo, nem sempre o "kill" mata o processo atingido.

Exerc�cio 2.15: tente reproduzir o exemplo que acabamos de dar.

2.15 [O que � hangup?] Suponha que voc� disparou um processo cuja execu��o ainda n�o encerrou, mas voc� precisa fechar a sess�o e ir embora para casa. Uma situa��o t�pica em que isso ocorre � quando se faz download de um arquivo grande pela Internet. O "logout" ir� abortar a execu��o daquele processo, exceto no caso em que ele foi protegido contra o "hangup".

O que vem a ser isso?

Quando a sess�o � encerrada, o processo n�o terminado n�o � abortado explicitamente. O que ocorre � que ele � submetido a um "hangup".

O unix pode enviar a qualquer processo um dentre v�rios "sinais". O sinal 9 por exemplo � o sinal "SIGKILL", e o efeito dele � invariavelmente abortar imediatamente a execu��o do processo. O sinal 15 costuma ser o "SIGTERM". A inten��o dele � "avisar" o processo que dentro de alguns segundos ele receber� um sinal "SIGKILL". Um editor de textos nesse momento salvar� todos os buffers para evitar a perda do trabalho do usu�rio. Voc� pode enviar qualquer um dos sinais a qualquer um dos seus processos atrav�s do comando "kill". De fato, a finalidade do comando "kill" n�o � matar um processo, mas enviar a ele um sinal.

O sinal 1 � o SIGHUP. O logout de que fal�vamos no in�cio faz com que os processos disparados naquela sess�o e ainda n�o encerrados recebam o sinal 1.

O sinal 1 � usado para fazer com que alguns processos importantes como o init ou o inetd releiam o seu arquivo de configura��o, com isso reconfigura-se um servidor sem interrup��o do servi�o. Fora esses casos, h� somente dois modos de um processo reagir ao sinal 1. O primeiro e mais comum � abortar. O segundo � ignorar o sinal.

A fim de que um processo possa ignorar o hangup � necess�rio que ele tenha sido preparado para isso. O modo de faz�-lo � usar o comando "nohup".

2.17 [Shell scripts] Todo processo foi um dia um arquivo execut�vel. Se fal�ssemos de processos sem criar um desde o in�cio, nossa exposi��o estaria incompleta. O arquivo execut�vel mais simples que podemos criar � um "shell script", que corresponde no msdos aos arquivos ".BAT".

Vejamos um exemplo elementar:

  hal:~$ ps ax
    PID TTY STAT  TIME COMMAND
      1  ?  S     0:00 init [5]             
      6  ?  S     0:00 bdflush (daemon)
      7  ?  S     0:00 update (bdflush)
     25  ?  S     0:00 /usr/sbin/crond -l10
     36  ?  S     0:00 /usr/sbin/syslogd
     38  ?  S     0:00 /usr/sbin/klogd
     40  ?  S     0:00 /usr/sbin/inetd
    101 v01 S     0:00 /sbin/agetty 38400 tty1 linux
    106  ?  Z     0:00 (atrun) 
     45 v02 S     0:00 -bash
    107 v02 R     0:00 ps ax

Digitando essas tr�s linhas e um Control-D ao final, voc� criar� um arquivo chamado "teste" no diret�rio corrente cujo conte�do s�o as duas linhas, aquela que come�a com "#" e a com o "ls".

A primeira informa ao sistema operacional que o interpretador a ser utilizado para executar o script � o shell /bin/sh, que costuma ser o interpretador default. A segunda vai executar um ls e redirecionar a linha para o wc, que vai contar o n�mero de linhas (op��o -l). Como o ls foi informado para colocar a sa�da em modo "longo" (op��o -l), o efeito do script � contar o n�mero de entradas do diret�rio corrente.

S� falta uma coisa para esse script funcionar. � necess�rio setar o atributo de executabilidade do arquivo teste. Maiores detalhes sobre isso ser�o dados na aula sobre filesystem. Por ora, basta sabermos que � necess�rio dar o seguinte comando:

  hal:~$ ps ax
    PID TTY STAT  TIME COMMAND
      1  ?  S     0:00 init [5]             
      6  ?  S     0:00 bdflush (daemon)
      7  ?  S     0:00 update (bdflush)
     25  ?  S     0:00 /usr/sbin/crond -l10
     36  ?  S     0:00 /usr/sbin/syslogd
     38  ?  S     0:00 /usr/sbin/klogd
     40  ?  S     0:00 /usr/sbin/inetd
    101 v01 S     0:00 /sbin/agetty 38400 tty1 linux
    106  ?  Z     0:00 (atrun) 
     45 v02 S     0:00 -bash
    107 v02 R     0:00 ps ax

A partir de agora o script pode ser executado como qualquer outro programa:

  hal:~$ ps ax
    PID TTY STAT  TIME COMMAND
      1  ?  S     0:00 init [5]             
      6  ?  S     0:00 bdflush (daemon)
      7  ?  S     0:00 update (bdflush)
     25  ?  S     0:00 /usr/sbin/crond -l10
     36  ?  S     0:00 /usr/sbin/syslogd
     38  ?  S     0:00 /usr/sbin/klogd
     40  ?  S     0:00 /usr/sbin/inetd
    101 v01 S     0:00 /sbin/agetty 38400 tty1 linux
    106  ?  Z     0:00 (atrun) 
     45 v02 S     0:00 -bash
    107 v02 R     0:00 ps ax

Shell scripts podem ser bastante complexos, incluindo comandos para intera��o com o usu�rio, controle de loops, varredura das entradas de um diret�rio, e muito mais.

Exerc�cio 2.18: siga os passos acima para criar o script teste e execute-o em v�rios diret�rios como /etc, /tmp, etc.

Exerc�cio 2.20: voc� sabe porque colocamos o "./" antecedendo o nome do script teste acima?

2.20 [Scripts em awk] Al�m dos shells, o unix conta com v�rios outros interpretadores que podem ser usados para a cria��o de scripts. Talvez o mais tradicional seja o awk. Outros que surgiram mais recentemente s�o o perl e o tcl. Os tr�s possuem vers�es para sistemas n�o-unix, inclusive msdos. O perl em particular � bastante poderoso e eficiente, sendo muito utilizado atualmente em servidores web.

A t�tulo ilustrativo daremos dois exemplos simples de scripts awk, que cont�m alguns dos conceitos fundamentais dessa linguagem.

Vamos ao primeiro. Note que ele � composto por tr�s blocos. O primeiro, com o label "BEGIN", � executado antes de qualquer leitura da entrada. O segundo � executado uma vez para cada linha lida da entrada, e o terceiro, com o label "END", � executado ao t�rmino da leitura da entrada.

  hal:~$ ps ax
    PID TTY STAT  TIME COMMAND
      1  ?  S     0:00 init [5]             
      6  ?  S     0:00 bdflush (daemon)
      7  ?  S     0:00 update (bdflush)
     25  ?  S     0:00 /usr/sbin/crond -l10
     36  ?  S     0:00 /usr/sbin/syslogd
     38  ?  S     0:00 /usr/sbin/klogd
     40  ?  S     0:00 /usr/sbin/inetd
    101 v01 S     0:00 /sbin/agetty 38400 tty1 linux
    106  ?  Z     0:00 (atrun) 
     45 v02 S     0:00 -bash
    107 v02 R     0:00 ps ax

O programa acumula na vari�vel t todos os n�meros lidos nas quintas colunas de cada linha da entrada, exceto quando essa quinta coluna cont�m a string "SIZE". Esse script foi feito para trabalhar em conjunto com o ps. Se voc� chamar o script de "s5", o modo de usar � assim:

  hal:~$ ps ax
    PID TTY STAT  TIME COMMAND
      1  ?  S     0:00 init [5]             
      6  ?  S     0:00 bdflush (daemon)
      7  ?  S     0:00 update (bdflush)
     25  ?  S     0:00 /usr/sbin/crond -l10
     36  ?  S     0:00 /usr/sbin/syslogd
     38  ?  S     0:00 /usr/sbin/klogd
     40  ?  S     0:00 /usr/sbin/inetd
    101 v01 S     0:00 /sbin/agetty 38400 tty1 linux
    106  ?  Z     0:00 (atrun) 
     45 v02 S     0:00 -bash
    107 v02 R     0:00 ps ax

Nosso segundo exemplo introduz um conceito important�ssimo em linguagens como awk e perl, a saber, o de "vetor associativo". Qualquer programador conhece o conceito de vetor, mas alguns nunca se depararam com vetores associativos. Neles, ao inv�s de �ndices num�ricos, t�m-se strings como �ndices. Isso � de extrema utilidade em processamento de texto de forma geral.

  hal:~$ ps ax
    PID TTY STAT  TIME COMMAND
      1  ?  S     0:00 init [5]             
      6  ?  S     0:00 bdflush (daemon)
      7  ?  S     0:00 update (bdflush)
     25  ?  S     0:00 /usr/sbin/crond -l10
     36  ?  S     0:00 /usr/sbin/syslogd
     38  ?  S     0:00 /usr/sbin/klogd
     40  ?  S     0:00 /usr/sbin/inetd
    101 v01 S     0:00 /sbin/agetty 38400 tty1 linux
    106  ?  Z     0:00 (atrun) 
     45 v02 S     0:00 -bash
    107 v02 R     0:00 ps ax

Se chamarmos o script de "grandes", ent�o a forma de us�-lo ser� "ls -l|grandes". A sa�da dele � composta pelos arquivos no diret�rio corrente com tamanho superior a 10000 bytes.

Exerc�cio 2.21: Teste os scripts dados neste par�grafo. Voc� pode seguir os passos descritos no par�grafo anterior para criar o arquivo e torn�-lo execut�vel. Se voc� tiver experi�ncia com algum editor de textos unix use-o.

2.21 [at e cron] � frequente programar-se a execu��o de processos para hor�rios de baixo uso da cpu ou de algum outro recurso, tipicamente de madrugada ou fins de semana. No unix isso � feito atrav�s do comando "at". Processos que necessitam ser executados de forma peri�dica, por exemplo uma limpeza di�ria em diret�rios de arquivos tempor�rios como /tmp, s�o disparados pelo "cron".

Processos disparados dessa forma n�o est�o amarrados a um terminal, e por isso n�o t�m para onde enviar a sua sa�da ou mensagens de erro, que via de regra s�o retornadas ao usu�rio por mail. Vejamos um exemplo.

  hal:~$ ps ax
    PID TTY STAT  TIME COMMAND
      1  ?  S     0:00 init [5]             
      6  ?  S     0:00 bdflush (daemon)
      7  ?  S     0:00 update (bdflush)
     25  ?  S     0:00 /usr/sbin/crond -l10
     36  ?  S     0:00 /usr/sbin/syslogd
     38  ?  S     0:00 /usr/sbin/klogd
     40  ?  S     0:00 /usr/sbin/inetd
    101 v01 S     0:00 /sbin/agetty 38400 tty1 linux
    106  ?  Z     0:00 (atrun) 
     45 v02 S     0:00 -bash
    107 v02 R     0:00 ps ax

O "at" executar� o script que ler da entrada padr�o (algumas implementa��es do "at" ao inv�s de ler um script da entrada padr�o esperam um nome de script na linha de comandos). No caso, a entrada padr�o � digitada manualmente e consiste apenas do comando "ls" (ap�s digitar o "ls" seguido do "enter", pressione control-d). Dentro de um minuto voc� receber� um mail com o conte�do do diret�rio corrente, e poder� l�-lo com o comando "Mail" (por exemplo).

Exerc�cio 2.22: Leia na man page do at de que formas voc� pode especificar um hor�rio para ele. Cheque tamb�m nessa man page como fazer para listar os jobs aguardando o momento da execu��o.

2.22 [o que s�o threads?] O advento da linguagem Java tem ajudado a popularizar o termo "thread". Do ponto de vista do usu�rio, � dif�cil distinguir "thread" de "processo", e na verdade h� livros que confundem os dois conceitos.

Se voc� j� acessou uma p�gina web com duas figuras se movimentando, ao mesmo tempo em que se pode usar o mouse e o teclado para preencher um formul�rio, ent�o voc� talvez tenha tido a impress�o de que havia v�rios processos em execu��o simult�nea, mas na verdade o que havia eram v�rios "threads".

A diferen�a entre processo e thread � que a �rea de dados de um processo � pr�pria, enquanto a de um thread n�o. Isso significa que cada processo tem a sua pr�pria �rea de dados, em geral inacess�vel aos outros, enquanto os threads compartilham uma mesma �rea de dados. � dif�cil visualizar exatamente o que significa isso sem conhecer aspectos internos de sistemas operacionais e sem ter no��es relativamente avan�adas de programa��o, mas como regra geral conv�m recordar que se tratam de conceitos distintos, e � por isso mesmo que possuem nomes distintos.

Como ver os processos no Linux?

Como podemos visualizar os processos correntes no sistema operacional Windows?

Como ver os serviços em execução no Linux?

Como ver os processos no Ubuntu?