O processo init
O processo init é o primeiro programa executado pelo kernel de qualquer sistema operacional Linux/Unix na sua inicialização.
Existem três versões do Init para o Linux para os serviços de inicialização do sistema: SysVinit, Upstart e o Systemd.
Neste artigo serão mostradas as diferenças de inicialização que existem entre as diversas distribuições Linux/Unix e como podemos personalizar a inicialização de um sistema Linux.
No momento em que o computador é ligado ou reinicializado (boot), o BIOS procura no primeiro setor do disco (master boot record) selecionado para carga do sistema operacional (que pode ser um disco rígido, um disquete, um CD-ROM, um ZIP-DRIVE ou um LS-120, e isto é definido no SETUP) um programa para executar, que será o carregador do sistema operacional (boot loader). O LILO e o GRUB são os programas de carga de sistema operacional mais comuns no Linux. Eles permitem selecionar qual partição será utilizada para carga do sistema operacional, possibilitando assim a escolha de múltiplos sistemas operacionais, ou mesmo versões diferentes do kernel do Linux.
Depois de carregado na memória, o kernel do Linux, normalmente compactado, é descompactado antes de iniciar a sua execução (isso é feito por meio de um pequeno programa colocado no início do arquivo do kernel do Linux). Logo em seguida, é exibida uma série de mensagens enviadas pelo kernel, durante a detecção e configuração do hardware existente no computador.
Depois de concluir a detecção e configuração do hardware, o kernel monta o root filesystem (o diretório /) a partir de um parâmetro fornecido ao LILO, pelo seu arquivo de configuração,
/etc/lilo.conf, ou ao GRUB, pelo seu arquivo de inicialização /boot/grub/menu.lst, e executa o processo init, que é o pai de todos os processos, carregando o programa /sbin/init. Todos os outros processos são denominados como sendo filhos deste e são monitorados pelo init. Este é o único processo que não pode ser abortado.
Existem dois estilos de inicialização para os sistemas operacionais Linux/Unix: SysV init e BSD init. A maioria das distribuições Linux utiliza inicialização estilo SysV init em virtude do maior número de recursos e da maior flexibilidade do que o BSD init.
SysV init
O sistema SystemV foi um dos mais utilizados (e por mais tempo) em diversas distribuições Linux e por isso é o mais conhecido entre os usuários. Ele funciona da seguinte forma:
- O kernel carrega o programa init, que é o binário principal do SystemV init;
- O init lê o arquivo de configuração /etc/inittab e identifica a linha que começa com si::sysinit: (system initialization). Esta linha contém o shell script que o init vai carregar logo após o kernel;
- O shell script /etc/rc.sysinit é então executado. Ele contém todas as tarefas básicas do sistema pós-kernel: monta os psudeo sistemas de arquivos (proc, sys, entre outros), carrega módulos do kernel, define configurações de kernel (sysctl), monta e verifica sistemas de arquivos, entre outros;
- Quando o script completa sua execução, o init espera por um nível de execução (runlevel). Como ele não tem nenhum ainda, ele lê a linha do /etc/inittab que tem a definição initdefault, e muda para este runlevel.
Por exemplo, em sistemas baseados em Red Hat:
1
2
|
# inicializa com o runlevel 3 (modo multi-usuário completo) id:3:initdefault: |
5.Ainda no /etc/inittab, existem linhas que indicam o que vai ser executado em cada runlevel. Neste caso, o SystemV usa as seguintes linhas:
1
2
3
4
5
6
7
|
l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6 |
Cada linha dessa executa o script /etc/rc.d/rc com o parâmetro do runlevel que o init mudou. Por exemplo, se o runlevel for 3, o init executa o /etc/rc.d/rc 3.
- O script /etc/rc.d/rc executa todos os arquivos executáveis do diretório /etc/rcX.d, onde X é o runlevel. Se o runlevel for 3, ele vai usar o diretório /etc/rc3.d;
- Dentro desses diretório, há diversos links simbólicos começando com K (de kill, ou seja, para o processo) ou S (de start, ou seja, inicia o processo). Os arquivos são executados em ordem alfabética, então ele executa o que começa com K e depois o que começa com S;
- Por fim, esses arquivos são todos links simbólicos para os reais scripts no diretório /etc/init.d. Estes scripts aceitam como parâmetros start (quando o link começa com S, o init chama o script com o parâmetro start) e stop (quando o link começa com K, o init chama o script com o parâmetro stop).
Formato do script init
O shell script do /etc/init.d deve aceitar, no mínimo, os parâmetros start e stop. Nada melhor que um exemplo para mostrar:
- Exemplo: /etc/init.d/meu-servico
#!/bin/bash # ### BEGIN INIT INFO # Provides: meu-servico # Required-Start: $network # Required-Stop: $network # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: O Meu Serviço # Description: Uma descricao mais completa sobre o meu serviço ### END INIT INFO # chkconfig: 2345 95 20 start() { echo 'Eu executei start!' > /var/log/meu-servico.log stop() { echo 'Eu executei stop!' > /var/log/meu-servico.log restart() { stop start case "$1" in start) start stop) stop restart) restart echo $"Usage: $0 {start|stop|restart}" exit 1 esac exit $?
|
Depois é só tornar o script executável:
Tenha em mente também que são shell scripts, então apesar do funcionamento ser geralmente o mesmo, o código pode variar bastante de script para script. Há uma diversidade de scripts em cada serviço de cada distribuição. Por isso, antes de fazer um script para seu serviço, dê uma olhada nos que já existem para sua distribuição e não se esqueça de aprender shell script.
Nota: Scripts são arquivos que agem como programas, passando instruções a um interpretador para realizar determinada tarefa. Diferente de programas compilados, scripts são arquivos de texto que podem ser manipulados em qualquer editor de texto não formatado.
Usando
Na prática, você já pode executar o script init com os comandos:
service meu-servico start
service meu-servico stop
service meu-servico restart
ou (prefira o service aos comandos diretos abaixo):
/etc/init.d/meu-servico start
/etc/init.d/meu-servico stop
/etc/init.d/meu-servico restart
Execute os comandos e veja o arquivo de log /var/log/meu-servico.log para cada um deles.
- Quando o serviço inicia, ele cria um arquivo contendo o PID do próprio serviço. Esses arquivos geralmente ficam em /var/run e terminam com extensão .pid;
- O shell script de init ao receber o parâmetro status procura esse arquivo. Se ele existir, o processo está rodando no PID contido no arquivo. Se o arquivo não existir, é porque o serviço não está rodando.
- Quando o serviço para, ele remove o arquivo contendo o seu PID.
Gerenciando os serviços na inicialização (runlevel)
Com o script colocado no lugar certo e com permissão de execução, existem comandos que gerenciam estes scripts e os colocam (fazem os links simbólicos) nos diretórios /etc/rcX.d corretamente.
- Distribuições baseadas em Red Hat
# inclui um serviço
chkconfig --add meu-servico
# habilita o serviço na inicialização
chkconfig meu-servico on
# desabilita o serviço na inicialização
chkconfig meu-servico off
# retira todos os links simbolicos
chkconfig --del meu-servico
# lista todos os serviços, e quando estão habilitados e desabilitados em quais runlevels
chkconfig --list
# lista apenas um serviço
chkconfig --list meu-servico
- Distribuições baseadas em Debian e Ubuntu
# inclui um serviço com prioridade 20 (o link fica como S20meu-servico)
update-rc.d meu-servico defaults
# inclui um serviço com prioridade 80 (o link fica como S90meu-servico)
update-rc.d meu-servico defaults 80
# retira todos os links simbolicos (-f é para forçar mesmo que o script exista no /etc/init.d)
update-rc.d -f meu-servico remove
Como funciona o /etc/inittab
O arquivo /etc/inittab contém a configuração principal do SystemV init. Na prática, para tudo que o comando init faz, este arquivo é consultado primeiro. Nele, temos uma configuração para cada linha. Anteriormente vimos que o init, ao mudar para o runlevel 3, executou uma série de arquivos dentro do /etc/rc3.d. Veja a linha dentro do /etc/inittab que fez isso:
l3:3:wait:/etc/rc.d/rc 3
Podemos dividir essa linha em campos separados por dois pontos (:), tendo assim os campos:
id:runlevels:ação:comando
Cada campo representa:
- id: um ID unico para identificar a linha, com até 4 caracteres.
- runlevels: quais os runlevels que essa linha vai funcionar (2345 significa que funciona no 2, no 3, no 4 e no 5)
- ação: o que fazer com essa linha (que ação tomar), explicado mais pra frente
- comando: qual comando/processo deve ser executado
Voltando ao exemplo anterior:
l3:3:wait:/etc/rc.d/rc 3
Significa: a linha de configuração l3 vai funcionar quando o runlevel for 3, vai executar o comando /etc/rc.d/rc 3 e esperar (wait) até o runlevel acabar ou mudar. Particularmente, o campo de ação pode ter várias opções. Algumas delas:
- respawn: executa o comando, e quando ele finalizar, executa-o novamente. Exemplos: terminais console (gettys);
- wait: executa o comando uma vez, mesmo quando ele finalizar, espera até o runlevel acabar ou mudar para saber o que fazer;
- sysinit: o primeiro comando que é executado logo após a inicialização (já explicado anteriormente);
- initdefault: qual o primeiro runlevel que o init ficar logo após a inicialização;
- ctrlaltdel: qual comando executar quando alguem precionar CTRL+ALT+DEL no terminal.
Alguns exemplos que podemos verificar:
x:5:respawn:/etc/X11/prefdm -nodaemon
No exemplo de cima, quando o sistema for pro runlevel 5, executar o comando /etc/X11/prefdm -nodaemon (que é o ambiente gráfico em sistemas baseados em Red Hat). Se o usuário sair do sistema gráfico, ele executa novamente (respawn).
2:2345:respawn:/sbin/mingetty tty2
No exemplo de cima, se o runlevel for 2, 3, 4 ou 5, executar o comando /sbin/mingetty tty2. Este comando é o console em modo texto do Linux (CTRL+ALT+F2). Se o usuário fizer logout no console, o processo é finalizado, mas o init executa novamente devido ao respawn.
Obs.: Os caracteres # (quase sempre), ; e ! (algumas vezes) são usados para fazer comentários, sendo ignorados todos os caracteres seguintes a eles que se encontram na mesma linha. No Linux/Unix, isto se aplica a todos os arquivos de configuração, scripts e programas-fonte.
O nível de execução atual do sistema pode ser visualizado pelo comando runlevel e modificado pelo comando init , onde n é o runlevel.
Upstart
O Upstart foi concedido para resolver as limitações do SystemV init para a distribuição Ubuntu e logo foi
adotado por outras distribuições Linux. Seu princípio é ser baseado em eventos: o Upstart cria um ou vários
eventos e os serviços podem ser associados à estes eventos. Ele é quem define o que fazer quando um evento
começa, muda ou termina (por exemplo: iniciando e parando serviços).
Se vários serviços estão dentro de um evento e ele ocorre, o Upstart pode por exemplo, iniciar todos estes
serviços paralelamente. Se um evento tem que ocorrer apenas depois de outro, quando o primeiro evento
terminar, ele começa a rodar este outro dependente. Mas vamos ver isso melhor.
Como antes, quando o kernel é iniciado, ele chama o daemon do Upstart, o /sbin/init. Este daemon, quando
iniciado, carrega todos os arquivos de configuração do diretório /etc/init. São todos os arquivos que tem
extensão .conf. Cada um desses arquivos define um Job. Este Job significa uma tarefa ou serviço. Vale notar
também que qualquer alteração nos arquivos vai ser imediatamente lida pelo Upstart, sem precisar recarregar ou
algo parecido.
Exemplo simples de um arquivo de configuração de job:
- /etc/init/hostname.conf
01 # hostname ‐ set system hostname 02 # 03 # This task is run on startup to set the system hostname from /etc/hostname, 04 # falling back to "localhost" if that file is not readable or is empty and 05 # no hostname has yet been set. 06 07 description "set system hostname" 08 09 start on startup 10 11 task 12 exec hostname ‐b ‐F /etc/hostname
Esta configuração de Job serve para, na inicialização da máquina, o sistema definir o seu nome lendo o arquivo
/etc/hostname. O que podemos ver de cara no exemplo:
Linha 7: uma descrição simples do que faz o job
Linha 9: qual estado executar e quando executar (neste caso, iniciar na inicialização
Linha 11: a configuração é uma tarefa: algo que vai ser executado e depois termina sozinho (exemplo:
um shell script)
Linha 12: O comando que será executado por esta tarefa.
Uma tarefa bem simples, não? Todos os scripts que tem a linha start on startup são os primeiros a serem
executados. O que acontece é que depois que o init é carregado e lê todas as configurações, ele emite o evento
startup. É deste evento que começa toda a cadeia de outros eventos (por exemplo, a tarefa hostname que
mostramos).
Resumo da inicialização:
Podemos resumir que a inicialização acontece então nesta ordem:
1. O upstart é iniciado pelo kernel, executando o /sbin/init;
2. O upstart lê todos os arquivos .conf do diretório /etc/init e define todos os jobs;
3. O upstart emite o evento startup;
4. Os jobs hostname e mountall são executados por causa do evento startup;
5. O job mountall emite os eventos: virtualfilesystems, localfilesystems, e por aí vai;
6. Devido ao evento virtualfilesystems…
1. O job procps é iniciado (configura os sysctls do arquivo /etc/sysctl.conf);
2. O job udev é iniciado (daemon udev que gerencia os eventos do kernel);
7. Devido ao evento localfilesystems…
1. O job dbus é iniciado (daemon de mensagens dbus)
2. O job networking é iniciado (interfaces de rede) apenas se os jobs udevcontainer
ou container
estiverem parados;
3. O job networking emite os eventos: staticnetworkup e netdeviceup;
4. Devido ao evento staticnetworkup…
1. O job procps pode ser iniciado (se já não foi antes);
2. O job rcsysinit é iniciado (serviços em runlevels, assim como no SystemV)…
1. Emite o evento runlevel, com o runlevel padrão 2 (em sistemas Debian);
2. Todos os jobs que estão inscritos no evento runlevel [2] são iniciados;
3. O job rc é iniciado (compatibilidade com o SystemV;
8. Devido ao evento netdeviceup…
1. O job mountallnet é iniciado (monta sistemas de arquivos remotos);
2. O job upstartsocketbridge é iniciado (recebe eventos em socket e retransmite pro upstart);
Runlevels
Como deu pra perceber no resumo da inicialização, os jobs mais simples e que não tem muitas dependências
podem obedecer o sistema de runlevels, criado pelo rcsysinit. Veja o exemplo do job atd:
- /etc/init/atd.conf
01 # atd ‐ deferred execution scheduler 02 # 03 # at is a standard UNIX program that runs user‐specified programs at 04 # scheduled deferred times 05 06 description "deferred execution scheduler" 07 08 start on runlevel [2345] 09 stop on runlevel [!2345] 10 11 expect fork 12 respawn 13 14 exec atd
- Ele vai ser iniciado quando o evento runlevel for chamado com o nível 2, 3, 4 ou 5.
- Ele vai ser parado quando o evento runlevel for chamado com o nível que não seja 2, 3, 4 ou 5.
Outras coisas legais de se falar sobre os runlevels:
- Se você mudar a variável DEFAULT_RUNLEVEL do arquivo rcsysinit.conf, você muda o runlevel
inicial do sistema. É a mesma coisa que alterar o initdefault do /etc/inittab no SystemV. Inclusive, o
Upstart lê um possível /etc/inittab para procurar por essa linha também; - O job rcsysinit também procura na linha do kernel (/proc/cmdline) por níveis de execução (s para single,
2 para runlevel 2, e por aí vai) e o usa para o runlevel inicial; - Um dos jobs que é chamado em todo runlevel é o rc, que é o modo de compatibilidade com o SystemV;
- O comando telinit emite um evento com o runlevel desejado, exemplo: telinit 3 emite o evento runlevel
[3].
Compatibilidade com o SystemV init
O modo com que o Upstart funciona faz dele bem flexível e abstrato. Por isso, dá para você pensar e montar
esquemas de gerência de serviços diversos. Um dos principais esquemas de serviços é justamente a
compatibilidade com o SystemV init. Imagine, se não colocassem uma compatibilidade, muita coisa poderia parar de funcionar de uma versão de distribuição para outra. Acho que ninguém ia querer isso né?
Uma das coisas que o job rcsysinit chama através do evento runlevel é o job rc. Este job, que é o responsável
pela compatibilidade SystemV, executa o script /etc/init.d/rc $RUNLEVEL, onde $RUNLEVEL é o runlevel
atual. Funciona igualzinho ao SystemV.
Em outras palavras, em sistemas novos com Upstart você não precisa se preocupar se existirem arquivos de
start/stop dentro do /etc/init.d. Inclusive o comando service também funcionará perfeitamente. Mas se você
estiver fazendo um serviço novo para as distribuições com Upstart, é recomendável usar o Upstart.
Manipulando os serviços
Até agora aprendemos como o Upstart funciona e como definir os seus serviços. Mas e para gerenciálos?
O comando do momento aqui é o initctl. Com ele você consegue gerenciar os serviços já existentes. Vamos aos
exemplos:
Listando todos os serviços disponíveis:
initctl list
Obs.: E não apenas lista, como mostra o status de cada um)
Os estados dos jobs / serviços
Ao fazer um initctl status job, podemos ver o estado do serviço, ou seja, em que fase de execução está o job.
Um job pode ter duas ações: start e stop. Cada uma dessas ações também tem seus estados e significam em que
ponto do start ou do stop o job está. Veja uma lista desses estados:
- waiting: Estado inicial (esperando algo acontecer);
- starting: Está para ser iniciado;
- prestart: Executando a seção prestart (preparação para iniciar);
- spawned: Executando a seção exec ou script
- poststart:Executando a seção poststart (depois que iniciou)
- running: O serviço está rodando
- prestop: Executando a seção prestop (preparação para parar)
- stopping: O serviço está parando
- killed: O serviço já parou, agora o job está quase para parar
- poststop: Executando a seção poststop (depois que parou)
Alguns exemplos:
# initctl status tty1 tty1 start/running, process 1265
O job tty1, que fornece a console 1 (CTRL+ALT+F1) está na fase de start (iniciar) e está em execução com o PID 1265.
# initctl status mountall mountall stop/waiting
O job mountall está na fase de stop (parou) e aguardando algo acontecer/mudar. Muitos jobs estarão neste estado, e isso pode significar que o job já foi executado uma vez (como é o caso desse exemplo).
Ligando e desligando serviços na inicialização
Nos sistemas SystemV, desligar ou ligar serviços na inicialização significava mexer nos links simbólicos do
diretório /etc/rcX.d (onde o X é o runlevel). No Upstart, as coisas mudam um pouco. Não há mais shell scripts
de execução, apenas configurações de job do /etc/init. O que fazer para impedir que eles sejam executados?
Primeiro identifique se o job é do tipo Upstart ou está utilizando o sistema legado SystemV.
Caso o serviço já tiver sido convertido para Upstart, o comando initctl status vai ficar assim:
# initctl status rsyslog rsyslog start/running, process 579
Se for do tipo SystemV, vai ficar assim:
# initctl status nscd initctl: Unknown job: nscd
(Não existe o job no Upstart (unknown job) mas existe o script /etc/init.d/nscd)
Se o script for do tipo SystemV, utilize os mesmos procedimentos da primeira parte deste tutorial.
Se for um job Upstart, você tem duas alternativas…
Desabilitando do boot
- Desde o Upstart 1.3, crie um arquivo de override para o job da seguinte forma:
# echo "manual" >> /etc/init/job.override
O parâmetro manual vai fazer com que o serviço só seja iniciado manualmente. O arquivo override é um
jeito de complementar a configuração do job sem ter que modificar o arquivo original;
- Ou se a versão for mais antiga, comente (colocar #) todas as linhas que começam com start na
configuração do job (/etc/init/job.conf).
Habilitando no boot
Partindo do suposto de que o serviço já está desabilitado:
- Desde o Upstart 1.3, apague o arquivo override:
# rm ‐f /etc/init/job.override
Ou se o arquivo override não existir, verifique e retire a linha manual dentro da configuração do job;
- Ou se a versão for mais antiga, descomente (tirar #) todas as linhas que começam com start na
configuração do job (/etc/init/job.conf).
Systemd
O systemd é um sistema de gerenciamento de serviços para o Linux, compatível com o SysV e Scripts de init LSB. Ele prove paralelização agressiva, utilizando socket e ativações D-Bus para iniciar serviços, oferece arranque de serviços sob demanda, mantém auditoria de processos através dos cgroups do Linux, suporta snapshotting e restauração de estado de sistema, mantém pontos de montagem mount e automount e implementa um elaborado sistema transacional baseado em dependências para controle lógico dos serviços. O systemd funciona como um substitudo por completo do sysvinit.
O systemd inicia e supervisiona o sistema como um todo, e é baseado na notação de unidades, compostas de um tipo que correspondem a um arquivo de configuração com o mesmo nome e tipo(ex: a unidade avahi.service é um arquivo de configuração de mesmo nome, que encapsula o daemon do Avahi). Existem sete tipos diferentes de unidades. A tradução das unidades não será feita por completo, visto que elas utilizam arquivos com a extensão em inglês, em seus arquivos de configuração:
service
– serviço: a mais óbvia das unidades: daemons que podem ser iniciados, parados, reiniciados e recarregados.socket
– socket: esta unidade encapsula um socket no sistema de arquivos ou na Internet. O systemd atualmente suporta sockets do tipo AF_INET, AF_INET6, AF_UNIX, de stream, datagrama e pacote sequencial. Também suporta os clássicos FIFOs como transporte. Cada unidade socket tem uma unidade service equivalente, que é iniciado quando a primeira conexão se iniciar ao um socket ou FIFO(ex: nscd.socket inicia o nscd.service em uma conexão de entrada).device
– dispositivo: esta unidade encapsula um dispositivo na árvore de dispositivos do Linux. Se um dispositivo é marcado através de regras no udev, ele será exposto a um dispositivo de unidade no systemd. Propriedadoes configuradas com o udev podem ser utilizadas como origem de configuração par o systemd, para ajustar dependencias entre dispositivos.mount
: esta unidade encapsula um ponto de montagem, na hierarquia do sistema de arquivos.automount
: este tipo de unidade encapsula um ponto de montagem automático(automount) na hierarquia do sistema de arquivos. Cada unidade automount, tem uma unidade mount correspondente, que é iniciada(montada) assim que o diretório automount é acessado.target
– alvo: este tipo de unidade é usado para agrupamento lógico de unidades. Ao invés de fazer algo, ela simplesmente referencia outras unidades, que podem ser controladas então de forma conjunta(ex: multi-user.target, é uma unidade que basicamente equivale a regra do run-level 5 no clássico SysV; ou o bluetooth.target que executa requisições assim que o bluetooth ficar disponível e simplesmente carrega serviços relacionados ao mesmo, que por algum motivo, não precisavam ser iniciados: bluetoothe a obexd por exemplo).snapshot
: similar a unidade target, a unidade snapshot não faz nada por si so a não ser referenciar outras unidades.
Características do systemd
O systemd possui as seguintes características:
- Paralelismo agressivo utilizando socket: Para aumentar o tempo de boot e o iniciar mais processos de forma paralela, o systemd cria os sockets de escuta antes de subir o serviço(daemon) e após este processo, apenas passa os sockets para eles. Todos os sockets referentes a todos os serviços são criados de uma vez durante o init, e então um segundo passo roda todos os daemons de uma vez. Se um serviço necessita outro que não está completamente pronto, acontecerá que a conexão é enfileirada no referente serviço e o cliente será bloqueado naquela requisição. Porém, apenas aquele cliente será bloqueado para aquela requisição. Desta forma, dependências entre serviços não necessitam ser configurados para uma inicialização paralelizada: todos os sockes são iniciados de uma vez, e um serviço quando precisar do outro, garantindo a conexão ao socket.
- Ativação D-Bus para iniciar serviços: Utilizando uma ativação bus, um serviço pode ser iniciado a primeira vez que é acessado. A ativação bus requer uma mínima sincronização por requisição para iniciar os provedores e consumidores de serviços D-Bus ao mesmo tempo: iniciando um serviço ao mesmo tempo que outro, e caso um seja mais rápido, então através de ativação bus o D-Bus enfileira a requisição até que outro serviço consiga se enomear.
- Oferece inicialização de daemons sob demanda
- Rastreamento de processos utilizando http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt cgroups]: Cada processo executado tem seu próprio cgroup e é muito fácil de configurar o systemd para interagir com cgroups configurados externamente, como por exemplo, através dos utilitários do libcgroups.
- Suporta snapshotting e restauração de estados do sistema: Snapshots podem ser utilizados para salvar/restaurar o estado de todos os serviços e unidades do sistema init. Possui dois casos de uso primários: permitir ao usuário para entrar temporariamente em algum estado, como uma “Shell de emergência”, terminando todos os processos correntes, e prover uma forma fácil para retornar ao estado anterior, subindo novamente dodos os serviços colocados em um estado temporário de “parada”.
- mantem pontos de montagem(mount) e montagem automática(automount): O systemd monitora todos os pontos de montagem e a forma como vão e chegam, e tambem pode ser utilizado para montar e desmontar pontos de montagem. /etc/fstab pode ser utilizado para configuração adicional para estes pontos de montagem. Utilizando a opção
comment=
no arquivo/etc/fstab
permite que as entradas podem ser automaticamente controladas pelo systemd, através de seu recurso de automount.
- implementa e elabora uma logica de controle de serviços transacional, baseado em dependências: O systemd suporte diversos tipos de dependências baseadas em serviços(ou unidades) utilizando as opções After/Before, Requires e Wants no arquivo de configurações de unidade para corrigir o ordenamento de como as unidades são ativadas. Requires e Wants, exprimem um requisito positivo de dependencia, mandatório ou opcional. Existe a expressão Conflicts, que exprime um requisito de dependência negativa, e outras expressões menos utilizadas. Como controle transacional, se uma unidade requer o inicio e parada, o systemd adicionará todas as dependências a uma transação temporária, verificando se a transação é consistente(ou o ordenamento através de After/Before de todas as unidades não forma um loop). Se não possuir sucesso, o systemd não tentará corrigir, removendo todas as ações não essenciais que podem acarretar no loop.
E:
- Para cada processo criado, ele controla: O ambiente, limites de recursos, diretório atual e root, umask, Ajuste de travas a OOM(falta de memória), nice, classe de IO e prioridade, política e prioridade de CPU, afinidade de CPU, timer, user id, group id, ids de grupos complementares, diretórios de leitura/escrita/inacessíveis, flags de montagem shared/private/slave, configurações de capabilities, secure bits, reinicio de scheduler de CPU, name-space privado de /tmp, controle de cgroup e vários subsistemas. Também pode facilmente conectar
stdin/stdout/stderr
para serviços comosyslog
,/dev/kmsg
, TTYs arbitrárias. Se uma TTY for conectada o systemd gerenciará o acesso exclusivo de processos, opcionalmente esperando, ou forçando.
- A configuração de arquivos do sistema possui uma sintaxe parecida da encontrada aos arquivos
.desktop
: É uma sinaxe simples, onde “parsers” existem em vários frameworks. Também permite a reutilização de ferramentas existentes para i18n para descrições de serviços, e similares, evitando que administradores de sistemas tenham que aprender novas sintaxes.
systemadm
Existe uma interface gráfica mínima, batizada systemadm
que permite a parada/inicio e instrospecção de serviços. Este é parte do pacote systemd-gtk e está em pesado desenvolvimento não sendo ainda funcional, porém é uma ferramenta util para debug. É escrita em Vala. Não utilize a não ser que você seja um desenvolvedor
- Compatibilidade com os antigos scripts SysV: Tomando vantagem da LSB e cabeçalhos chkconfig quando disponíveis, se não, utiliza as informações constantes em outras localizações como por exemplo, as em /etc/rc.d. Estes init scripts são simplesmente considerados diferentes fontes de configuração, provendo um fácil caminho de atualização para o systemd.
- arquivo de configuração /etc/fstab: apenas uma outra fonte de configuração. Utilizando a opção do fstab comment=, é possível marcar as entradas do /etc/fstab para serem controladas pelo systemd, através de pontos automáticos de montagem.
- Suporte a simples mecanismo de template/instancias: Por exemplo, ao invés de possuir seis arquivos de configuração para seis gettys, apenas um arquivo enomeado getty@.service que será inicializado para getty@tty2.service e assim por diante. A parte de interface do systemd pode herdar dependências através de expressões como por exemplo, o serviço dhcpcd@eth0.service, que carrega o avahi-autoipd@eth0.service deixando a string eth0 como coringa de dependência.
- Compatibilidade, em partes com o
/dev/initctl
. Esta compatibilidade é de fato implementada através de serviços ativados via FIFO, que apenas traduz estas requisições legadas para requisições D-Bus. Efetivamente, isto signigica que antigos comandos de shutdown, poweroff e similares do Upstart e sysvinit continuam a funcionar com o systemd.
- Compatibilidade com
utmp
ewtmp
(Extendendo de forma mais saudável, levando em conta o quão crufty owtmp
eutmp
são).
Ferramentas
systemctl
: utilizado para inspecionar e controlar o estado do sistema systemd e gerenciador de serviços.systemd-cgls
: exibe recursivamente o conteúdo da árvore de hierarquia de um determinado grupo de controle do Linux.systemadm
: interface grávica pra gerenciamento de serviços no systemd que permite inspecionar e controlar o systemd. éÉ parte do pacote systemd-gtk. Não utilize a não ser que você seja um desenvolvedor, pois está em uma versão não muito madura.
Referências:
Devin:www.devin.com.br
Fedora Project: https://fedoraproject.org/wiki/Systemd/pt-br
Wiki Ubuntu: https://wiki.ubuntu.com/SystemdForUpstartUsers