[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ] [ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ próximo ]
Quando foi criado o primeiro Unix em 1970 por Ken Thompson e Denis Ritchie, seu nome foi um batismo pela mudança de filosofia de seu antecessor, multics, que era time-sharing, para um sistema com um único processo que se iniciava e controlava o restante do sistema: o init. Único e Unix. Entendeu a brincadeira?
Quando Linux começou a surgir como sistema operacional, foi adotado um sistema
de init compatível com padrão SYSV, que basicamente lia os scripts colocados
em /etc/init.d/rc<n>.d no padrão de
RedHat/Suse, ou em /etc/rc<n>.d no padrão
Debian, e inicializava como shell script, rodando /bin/sh todos os
scripts que começassem com S. Cada diretório de
inicialização tinha um <n> referente ao corrente
runlevel. Então um boot em initlevel 5, todos os scripts em
/etc/rc5.d/S* seriam lidos. Não somente lidos, mas executados
como script e tendo como argumento o parâmetro start.
Em termos bem simplistas, o que o init padrão SYSV fazia era (usando Debian como exemplo):
level=$(runlevel | cut -d" " -f 2) # ler qual o runlevel atual
for script in /etc/rc${level}.d/S*
do
/bin/sh $script start
done
Da mesma forma, ao mudar de runlevel (o que acontecia ao desligar o sistema), os scripts que tinham K como primeira letra eram executados com o argumento stop
Assim por muitos anos os sistemas GNU/Linux viveram felizes inicializando e terminando seus sistemas. Em geral qualquer um poderia criar um script de inicialização utilizando um formato parecido com o seguinte:
#! /bin/sh
case $1 in
start) fazendo coisas de start ;;
stop) fazendo coisas de stop ;;
status) verificando se está rodando ou não;
restart) $0 stop
$0 start
;;
*) echo "Use: $0 [start|stop|status]"
esac
O problema de toda essa bela simplicidade é que se por algum motivo a parte do script que era chamada parasse, os outros scripts não eram executados. Isso levava geralmente os scripts de inicialização pouco testados a gerar belos travamentos em servidores depois de reboots.
A primeira solução adotada foi a mais óbvia: colocar todo mundo pra rodar em background usando &. Essa solução era perfeita e resolvia o problema de travamento na inicialização mas... (sempre tem um mas) alguns scripts dependiam de outros scripts, que não tinham terminado de inicializar. Então veio o segundo problema: ordenação desses scripts.
O Upstart, desenvolvido pela Canonical, tinha como objetivo substituir o daemon init do Linux, tendo como grande trunfo ser orientado a eventos. Isso significa que, um evento pode iniciar um serviço, que inicia outro evento e dispara outro serviço, e assim consecutivamente. Tinha como meta compatibilidade total com o init System V, podendo rodar scritps deste init sem modificações.
Semelhante ao Upstart, porém, o Systemd elimina o uso de scritps de inicialização. Apesar disso, este sistema e gerenciador de serviços pode criar chamadas para scripts no momento da inicialização. Seu paralelismo é mais agressivo que o Upstart e utiliza sockets D-Bus (mecanismo de intercomunicação entre processos concorrentes). Ele, o Systemd, se propõe a realizar a inicialização do sistema de forma mais rápida, usando paralelismo e ordem de prioridade. Para garantir que o sistema inicialize mais rapidamente o Systemd acaba por controlar parte do hardware, como :
Reconhecimento de Hardware
Montagem de Dispositivo
Permissões de Montagem
Tomando conta do hardware o sistema fica dependente do Systemd. Como é quase todo binário sua alteração, e conseguente controle do usuário torna-se complexa, e muitas vezes o usuário fica refém do binário, sem poder alterá-lo. De certa forma, ele pode ser utilizado em qualquer distribuição Linux, mas tem mostrado melhor desempenho nas distribuições Debian, Red Hat e seus derivados.
Os comandos podem ser utilizados em qualquer distribuição.
Verificando a versão instalada do systemd:
$ systemctl --version
Verificar o tempo de boot do sistema:
$ systemd-analyze
Verificar processos por grupos de controle:
# systemd-cgtop
Exibir uma lista de todas as units (serviços, pontos de montagem, devices):
# systemctl
Ativando o serviço "exemplo":
# systemctl start exemplo
Desativando "exemplo":
# systemctl stop example
Reiniciando o serviço "exemplo"
# systemctl restart exemplo
Verificando o status de "exemplo":
# systemctl status exemplo
Habilitando "exemplo" para iniciar no boot:
# systemctl enable exemplo
Desativando "exemplo" para que não inicie no boot:
# systemctl disable example
[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ] [ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ próximo ]
Guia Foca GNU/Linux
Versão 4.22 - domingo, 05 de setembro de 2010mailto:gleydson@guiafoca.org