<Anterior | Conteúdo | Próxima>

O -u e -a opções fornecem informações adicionais. Para obter mais opções e o que eles fazem, consulte as páginas de informações.

Na próxima seção, veremos como um processo pode criar outro.

4.1.5. Vida e morte de um processo

4.1.5.1. Criação de processo

Um novo processo é criado porque um processo existente faz uma cópia exata de si mesmo. Este processo filho tem o mesmo ambiente que seu pai, apenas o número de identificação do processo é diferente. Este procedimento é chamado bifurcação.

Após o processo de bifurcação, o espaço de endereço do processo filho é sobrescrito com os novos dados do processo. Isso é feito por meio de um exec ligue para o sistema.

O fork-and-exec mecanismo, portanto, troca um comando antigo por um novo, enquanto o ambiente no qual o novo programa é executado permanece o mesmo, incluindo configuração de dispositivos de entrada e saída, variáveis ​​de ambiente e prioridade. Esse mecanismo é usado para criar todos os processos UNIX, portanto, também se aplica ao sistema operacional Linux. Mesmo o primeiro processo, o init, com ID de processo 1, é bifurcado durante o procedimento de inicialização no

assim chamado bootstrapping procedimento.

Este esquema ilustra o mecanismo fork-and-exec. O ID do processo muda após o procedimento de bifurcação:

Figura 4-1. Mecanismo fork-and-exec

Existem alguns casos em que o init torna-se o pai de um processo, enquanto o processo não foi iniciado por o init, como já vimos no ptree exemplo. Muitos programas, por exemplo, demonizar seus processos filho, para que possam continuar em execução quando o pai parar ou estiver sendo interrompido. Um gerenciador de janelas é um exemplo típico; começa um xterm processo que gera um shell que aceita comandos. O gerenciador de janelas então nega qualquer responsabilidade adicional e passa o processo filho para o init. Usando este mecanismo, é possível mudar os gerenciadores de janela sem interromper os aplicativos em execução.

De vez em quando, as coisas dão errado, mesmo em boas famílias. Em um caso excepcional, um processo pode terminar enquanto o pai não espera pela conclusão desse processo. Esse processo não enterrado é chamado de zumbi processo.

4.1.5.2. Processos finais

Quando um processo termina normalmente (não é eliminado ou interrompido inesperadamente), o programa retorna seu status de saída para o pai. Este status de saída é um número retornado pelo programa, fornecendo os resultados da execução do programa. O sistema de retorno de informações ao executar um trabalho tem sua origem na linguagem de programação C na qual o UNIX foi escrito.

Os códigos de retorno podem ser interpretados pelo pai ou em scripts. Os valores dos códigos de retorno são específicos do programa. Essas informações geralmente podem ser encontradas nas páginas de manual do programa especificado, por exemplo, o grep comando retorna -1 se nenhuma correspondência for encontrada, em que uma mensagem nas linhas de "Nenhum arquivo encontrado" pode ser impressa. Outro exemplo é o comando embutido Bash verdadeiro, que não faz nada, exceto retornar um status de saída 0, o que significa sucesso.

4.1.5.3. Sinais

Os processos terminam porque recebem um sinal. Existem vários sinais que você pode enviar para um processo. Use o matar comando para enviar um sinal para um processo. O comando matar -l mostra uma lista de sinais. A maioria dos sinais é para uso interno do sistema ou para programadores quando escrevem códigos. Como usuário, você precisará dos seguintes sinais:

Tabela 4-2. Sinais comuns

Você pode ler mais sobre as ações padrão que são tomadas ao enviar um sinal para um processo em homem 7 sinal.

4.1.6. SUID e SGID

Conforme prometido no capítulo anterior, discutiremos agora os modos especiais SUID e SGID com mais detalhes. Esses modos existem para fornecer aos usuários normais a capacidade de executar tarefas que normalmente não seriam capazes de fazer devido ao esquema de permissão de arquivo rígido usado em sistemas baseados em UNIX. Na situação ideal, os modos especiais são usados ​​da maneira mais esparsa possível, pois incluem riscos de segurança. Os desenvolvedores Linux geralmente tentam evitá-los tanto quanto possível. O Linux ps versão, por exemplo, usa as informações armazenadas no / proc sistema de arquivos acessível a todos, evitando a exposição de dados e recursos sensíveis do sistema ao público em geral. Antes disso, e ainda em sistemas UNIX mais antigos, o ps programa precisava de acesso a arquivos como / dev / mem e / dev / kmem, que apresentava desvantagens devido às permissões e propriedades desses arquivos:

Com versões mais antigas de ps, não era possível iniciar o programa como um usuário comum, a menos que modos especiais fossem aplicados a ele.

Embora geralmente tentemos evitar a aplicação de quaisquer modos especiais, às vezes é necessário usar um SUID. Um exemplo é o mecanismo de alteração de senhas. Claro que os usuários vão querer fazer isso sozinhos, em vez de ter sua senha definida pelo administrador do sistema. Como sabemos, os nomes de usuário e senhas estão listados no / Etc / passwd arquivo, que tem as seguintes permissões de acesso e proprietários:

bea: ~> ls -l / etc / passwd

-rw-r - r-- 1 raiz

1267 16 de janeiro 14:43 / etc / passwd

bea: ~> ls -l / etc / passwd

-rw-r - r-- 1 raiz

Ainda assim, os usuários precisam ser capazes de alterar suas próprias informações neste arquivo. Isso é conseguido dando o passwd

permissões especiais do programa:

mia: ~> qual senha

passwd é / usr / bin / passwd

mia: ~> qual senha

passwd é / usr / bin / passwd

mia: ~> ls -l / usr / bin / passwd

-rs - x - x 1 raiz raiz

13476 de agosto de 7 06:03 / usr / bin / passwd *

mia: ~> ls -l / usr / bin / passwd

-rs - x - x 1 raiz raiz

Quando chamado, o passwd comando será executado usando as permissões de acesso de raiz, permitindo assim que um usuário comum edite o arquivo de senha que pertence ao administrador do sistema.

Os modos SGID em um arquivo não ocorrem com tanta frequência quanto o SUID, porque o SGID geralmente envolve a criação de grupos extras. Em alguns casos, no entanto, temos que passar por esse problema para construir uma solução elegante (não se preocupe muito com isso - os grupos necessários geralmente são criados na instalação). Este é o caso do escrever e parede programas, que são usados ​​para enviar mensagens para terminais de outros usuários (ttys). o escrever comando escreve uma mensagem para um único usuário, enquanto parede escreve para todos os usuários conectados.

O envio de texto para o terminal ou display gráfico de outro usuário normalmente não é permitido. Para contornar este problema, foi criado um grupo, que possui todos os dispositivos terminais. Quando o escrever e parede comandos recebem permissões SGID, os comandos serão executados usando os direitos de acesso aplicáveis ​​a este grupo, tty no exemplo. Uma vez que este grupo tem acesso de escrita ao terminal de destino, também um usuário sem permissão para usar aquele terminal de qualquer forma pode enviar mensagens para ele.

No exemplo abaixo, o usuário joe primeiro descobre em qual terminal seu correspondente está conectado, usando o que comando. Em seguida, ele envia uma mensagem para ela usando o escrever comando. Também são ilustrados os direitos de acesso no escrever programa e nos terminais ocupados pelo usuário receptor: é claro que outras pessoas além do proprietário do usuário não têm permissões no dispositivo, exceto para o proprietário do grupo, que pode escrever nele.

joe: ~> qual escrever

escrever é / usr / bin / write

joe: ~> ls -l / usr / bin / write

-rwxr-sr-x 1 raiz tty

8744 5 de dezembro, 00:55 / usr / bin / write *

joe: ~> qual escrever

escrever é / usr / bin / write

joe: ~> ls -l / usr / bin / write

-rwxr-sr-x 1 raiz tty

joe: ~> que

Jenny tty1

Jenny pts / 1

Jenny pts / 2

Jenny pts / 3

joe pts / 0

Jan 23 11: 41

23 de janeiro, 12:21 (: 0)

23 de janeiro, 12:22 (: 0)

23 de janeiro, 12:22 (: 0)

20 de janeiro 10:13 (lo.callhost.org)

joe: ~> que

Jenny tty1

Jenny pts / 1

Jenny pts / 2

Jenny pts / 3

joe pts / 0

joe: ~> ls -l / dev / tty1

crw - w ---- 1 Jenny tty 4,

1 ° de 23 de janeiro 11h41 / dev / tty1

joe: ~> ls -l / dev / tty1

crw - w ---- 1 Jenny tty 4,

joe: ~> escrever Jenny tty1

ei Jenny, vamos almoçar juntos?

^C

joe: ~> escrever Jenny tty1

ei Jenny, vamos almoçar juntos?

^C

Utilizador jenny fica com isso na tela:

Mensagem de [email protected] no ptys/1 às 12h36... ei Jenny, vamos almoçar juntos?

EOF

Mensagem de [email protected] no ptys/1 às 12h36... ei Jenny, vamos almoçar juntos?

EOF

Depois de receber uma mensagem, o terminal pode ser limpo usando o Ctrl+L combinação de teclas. Para não receber nenhuma mensagem (exceto do administrador do sistema), use o mensagem comando. Para ver quais usuários conectados aceitam mensagens de outras pessoas, use que -w. Todos os recursos são totalmente explicados nas páginas de informações de cada comando.

Os nomes dos grupos podem variar

O esquema de grupo é específico para a distribuição. Outras distribuições podem usar outros nomes ou outras soluções.

<Anterior | Conteúdo | Próxima>