User:Deadc/systemd

Retirado da pagina do projeto

"systemd is a system and service manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. It can work as a drop-in replacement for sysvinit."

Nota: Para uma explicação detalhada do porque o Arch está migrando para o systemd, veja esta thread no fórum oficial.

Veja também o artigo na Wikipedia.

Considerações antes da migração

É recomendado substituir os antigos arquivos de configuração do initscripts descritos no artigo do rc.conf. Uma vez refeita a configuração, boa parte do trabalho necessário para o uso do systemd estará feita

Faça alguma leitura a respeito do systemd

O systemd utiliza um sistema de Journal, que substitui o atual syslog, muito embora seja possível que os dois co-existam no mesmo sistema. leia mais a respeito na seção Journal.

Apesar do systemd substituir algumas funcionalidades do cron,acpid e xinetd, não é necessário deixar de usar estes serviços.

Instalação

O systemd pode ser usado paralelamente ao pacote initscripts utilizado pelo Arch Linux, a troca entre os sistemas ocorre inserindo o parametro init=/bin/systemd ao kernel.

Instalação paralela systemd/sysvinit/initscripts

É possível manter o systemd e o sysvnit ambos instalados e usando os mesmos arquivos de configuração, assim você pode utilizar um ou outro livremente:

Reconfigure seu sistema removendo os antigos parametros de configuração utilizados pelo initscripts no arquivo rc.conf (você deverá ver vários warnings durante o boot) e utilize as configurações nativas do systemd.
Instale o systemd a partir dos repositórios oficiais
Adicione o parametro init=/bin/systemd a linha do kernel no seu bootloader
Reinicie o seu sistema

o systemd deverá iniciar os serviços configurados no /etc/rc.conf e rodar os scripts /etc/rc.local e /etc/rc.local.shutdown no boot e shutdown respectivamente. Se a configuração legada para o parametro DAEMONS no rc.conf ou os scripts no rc.local não forem mais necessários, eles poderam ser desabilitados.

Atenção: No caso de existirem serviços configurados no rc.conf dos quais também existam dentro dos arquivos de serviços do systemd, os serviços do systemd teram precedência. Porém, se o nome do serviço no rc.conf for diferente do configurado no systemd, o processo de inicialização do serviço irá falhar e você terá que verificar se apenas um dos dois (preferencialmente o nativo) está ativo.

Instalação paralela systemd/initscripts

É possivel substituir o sysvinit pelo systemd, mantendo o initscripts para no caso de ainda não houver algum script rc equivalente no systemd.

Siga as instruções para utilização paralela do systemd/sysvinit/initscripts
Habilitar os serviços antes listados no rc.conf com o comando systemctl enable nomedoservico.service para migrar para os serviços nativos do systemd, veja lista de serviços pré-existentes. deverão ser mantidos no parâmetro DAEMONS do rc.conf os serviços que ainda não existirem no systemd.
Instalar o systemd-sysvcompat, este pacote conflita com o sysvinit, aparecerá uma mensagem solicitando remove-lo.
Remover a entrada init=/sbin/systemd dos parametros do kernel, /sbin/init agora deverá ser um link simbólico para o systemd.
Reiniciar o sistema.

A diferença entre este processo e de manter o sysvinit no sistema é que todos os binários antes usados pelo sysvinit serão substituidos por links simbólicos para o systemctl, sem que com isso, as funcionalidades sejam alteradas.

Instalação simples do systemd

Por ultimo, é possível utilizar o systemd somente, removendo o initscripts e o sysvinit.

Siga as instruções para uma instalação paralela do systemd/initscripts.
Tenha certeza que não exista mais nenhum serviço sendo iniciado pelo parametro DAEMONS no /etc/rc.conf, e que os arquivos /etc/rc.local e /etc/rc.local.shutdown estejam vazios.
Remova o pacote initscripts do sistema.

Dica: se você tiver o parametro quiet na linha de inicialização do kernel, é recomendado que você remova nas primeiras inicializações com o systemd para identificar algum problema durante o boot

Configurações nativas do systemd

Nota: Alguns arquivos deverão ser criados caso não existam.Todos estes arquivos devem ter permissões 644 e a propriedade de root:root

O systemd irá utilizar os parametros legados configurados no /etc/rc.conf caso não encontre os arquivos de configuração nativos, note que esta solução é temporaria e é extremamente recomendado que seja utilizado os novos arquivos de configuração do systemd.

Hostname (Nome da Máquina)

 O Nome da Máquina é configurado em /etc/hostname. O arquivo não deve conter o domínio do sistema , se existir. 
Para configurar o Nome da Máquina, faça: 
hostnamectl set-hostname nome_da_máquina

Console e Keymap(layouts de teclado)

o arquivo /etc/vconsole.conf define as configurações do console virtual,
ex: layout do teclado e a fonte utilizada no console

/etc/vconsole.conf

KEYMAP=br-abnt2
FONT=lat0-16
FONT_MAP=

Para mais informações visite Console fonts e Keymap.

Time zone (Fuso horário)

Leia man 5 localtime para mais opções.

# ln -sf /usr/share/zoneinfo/America/Sao_Paulo /etc/localtime

Nota: /etc/timezone está obsoleto no systemd-190 e pode ser removido.

Locale(Localização)

A escolha do idioma (locale) predeterminado do sistema é configurado em /etc/locale.conf. Para definir o idioma predeterminado, digitar:

localectl set-locale LANG="pt_BR.UTF-8"

Nota: Antes de definir o idioma padrão é necessário habilitar um dos locale disponíveis para o sistema, descomentando o idioma em /etc/locale.gen e em seguida executar o comando locale-gen como root.
O idioma definido através de localectl deve ser o mesmo que foi descomentado no arquivo /etc/locale.gen.

Leia o man locale.conf para mais opções:

/etc/locale.conf

pt_BR.UTF-8 UTF-8

Para mais informações visite Locale

Hardware clock time (Hora em relógio de hardware)

Systemd irá usar o UTC para o hardware clock por padrão e este é o modo recomendado. Se o DST mudar quando seu computador estiver desligado, seu relógio será definido errado no próximo boot (há muito mais do que isso). Versões de kernel mais recentes definem a data do sistema diretamente do RTC no boot sem utilizar o hwclock, o kernel sempre irá assumir que o RTC está em UTC. isto significa que se o RTC estiver em localtime, a data do sistema será definida erroneamente e então corrigida rapidamente em cada boot. esta pode ser a razão de alguns bugs relacionados a hora/data atrasada.

A razão para permitir o RTC ser definido em localtime é utilizar dual boot com o Windows (que utiliza o localtime). o Windows é capaz de lidar com o RTC em localtime com uma simples alteração no registro. se você tiver problemas com o dual boot do Windows você poderá definir o hardware clock em localtime.

/etc/adjtime

0.0 0.0 0.0
0
LOCAL

Os outros parametros ainda serão necessários mas ignorados pelo systemd.

É geralmente recomendado a utilização do Network Time Protocol daemon para manter o hardware clock sincronizado com o horário do sistema.

Módulos do kernel no boot

systemd utiliza arquivos com uma lista estática dentro do diretório /etc/modules-load.d/ para configurar os módulos do kernel carregados durante o boot. Cada arquivo de configuração segue o padrão /etc/modules-load.d/<programa>.conf.
Os arquivos de configuração devem conter uma lista de nomes dos módulos a serem carregados, e devem ser separados por uma nova linha. Exemplo:

/etc/modules-load.d/virtio-net.conf

# Carrega virtio-net.ko durante o boot
virtio-net

Veja também Modprobe#Options.

Módulos do kernel na blacklist

Inserir módulos do kernel na blacklist funciona da mesma forma utilizada no initscripts uma vez que o systemd também utiliza o kmod para gerencia-los. Veja Module Blacklisting para detalhes.

Arquivos temporários

O systemd-tmpfiles utiliza os arquivos de configuração em /usr/lib/tmpfiles.d/ e /etc/tmpfiles.d/ para definir a criação, limpeza e remoção de arquivos voláteis, arquivos temporários e diretórios que antes existiam em diretórios como /run ou /tmp. Cada arquivo de configuração é nomeado na forma /etc/tmpfiles.d/<programa>.conf. Arquivos de configuração em /etc/tmpfiles.d/ terão precedência caso existam com o mesmo nome em /usr/lib/tmpfiles.d/.

tmpfiles são comumente distribuidos junto com os arquivos de serviço para criar diretórios e permissões necessárias, por exemplo o Samba espera que o diretorio /var/run/samba exista e tenha as permissões corretas. o tmpfile correspondente seria assim:

/usr/lib/tmpfiles.d/samba.conf

D /var/run/samba 0755 root root

tmpfiles também podem ser usados para escrever em arquivos no boot, por exemplo se você usa o /etc/rc.local para desabilitar o wakeup de dispositivos USB com echo USBE > /proc/acpi/wakeup, você deverá usar o seguinte tmpfile:

/etc/tmpfiles.d/disable-usb-wake.conf

w /proc/acpi/wakeup - - - - USBE

A utilização do tmpfile neste caso é recomendada já que o systemd atualmente não suporta o arquivo /etc/rc.local.

Veja man tmpfiles.d para detalhes.

Partições remotas

Systemd automaticamente se certifica que partições remotas como NFS ou Samba somente serão iniciadas se a rede estiver configurada e funcionando.
No entanto partições remotas configuradas no /etc/fstab deverão funcionar out-of-box

Você também poderá utilizar o Automount para que as partições remotas sejam montadas apenas quando acessadas.
Alem disso, poderá usar a opção x-systemd.device-timeout=# no /etc/fstab para especificar um timeout em caso da rede não estiver disponível.

Veja man systemd.mount para detalhes.

ACPI Power Management com systemd (Gerenciamento de energia com ACPI no systemd)

Systemd trabalha com alguns eventos ACPI, e isso é possivel através das opções no arquivo /etc/systemd/logind.conf:

HandlePowerKey: Especifica qual ação será realizada quando power key for pressionado.
HandleSuspendKey: specifica qual ação será realizada quando suspend key for pressionado.
HandleHibernateKey: specifica qual ação será realizada quando hibernate key for pressionado.
HandleLidSwitch: specifica qual ação será realizada quando lid for fechado.

As ações que podem ser definidas são ignore, poweroff, reboot, halt, suspend, hibernate ou kexec.

Se nenhuma dessas opções for configurada, o systemd irá utilizar o seu padrão: HandlePowerKey=poweroff, HandleSuspendKey=suspend, HandleHibernateKey=hibernate, e HandleLidSwitch=suspend.

Em sistemas onde a interface gráfica não é utilizada ou exista window managers mais simples como i3 ou awesome, esta configuração pode substituir completamente o acpid que usualmente gerencia estes eventos.

Na versão atual do systemd, as opções de Handle serão aplicadas em todo o sistema, a menos que estas opções sejam "inibidas" (temporariamente desligadas) por um programa, como um gerenciador de energia dentro de um ambiente de desktop, o Xfce por exemplo. Se essas "inibições" não forem feitas, você poderá acabar com uma situação em que systemd suspende o seu sistema, então, quando retorna o gerenciador de energia de outro programa irá suspende-lo novamente.

Nota: Atualmente, somente o gerenciador de energia da ultima versão do KDE consegue realizar as "inibições" necessárias. caso prefira utilizar gerenciadores do GNOME,Xfce,acpid ou outro, você terá que definir as opções de Handle para ignore.

Hooks do modo de espera(Sleep hooks)

Systemd não utiliza o pacote pm-utils para colocar o computador em modo de espera quando é utilizado systemctl suspend ou systemctl hibernate,
além disso os hooks do pm-utils incluindo hooks customizados não serão executados. no entanto, o systemd oferece um mecanismo similar para executar scripts customizados neste tipo de evento.
Systemd utiliza o diretório /usr/lib/systemd/system-sleep/ para seus scripts e informa dois argumentos para cada um deles:

Argumento 1: pre ou post, dependendo se a máquina será colocada em modo de espera ou se está retornando a ativação
Argumento 2: suspend ou hibernate, dependendo de qual evento.

Em contraste com o pm-utils, systemd irá executar estes scripts concorrentemente e não um após o outro.

A saída do seu script será salvo em systemd-suspend.service ou systemd-hibernate.service podendo ser consultado através do journal.

Você ainda poderá utilizar sleep.target, suspend.target ou hibernate.target para ligar units dentro da lógica de sleep ao invés de utilizar scripts.

Veja man systemd.special e man systemd-sleep para maiores informações.

Exemplo

/usr/lib/systemd/system-sleep/example.sh

#!/bin/sh

case "$1" in
  pre )
    echo going to $2 ...
    ;;
  post )
    echo waking up from $2 ...
    ;;
esac

Unidade

Um arquivo de configuração unidade agrega informações sobre um serviço, um socket, um dispositivo, um ponto de montagem, um ponto de montagem automatico, um arquivo swap ou partição, um script de inicialização, um caminho no sistema de arquivos ou um cronometro controlado e supervisionado pelo systemd. A sintaxe é inspirada no XDG Desktop Entry Specification que utiliza arquivos com a extensão .desktop , parecida com os arquivos .ini do Windows. Veja man systemd.unit para mais informações.

Comandos do systemd

systemctl: usado para a introspecção e controle do estado do systemd além de gerenciar os serviços.
systemd-cgls: Recursivamente exibe os grupos de controle selecionados em estrutura de árvore, como o pstree.
systemadm: Interface gráfica para o sistema do systemd e gerenciamento dos serviços que permite a introspecção e controle do systemd (Disponível via systemd-ui-git^AUR,

Veja as man pages para maiores informações.

Dica: Você pode utilizar o comando systemctl com o parametro -H <user>@<host> para controlar o systemd de uma máquina remota. este parametro irá utilizar o SSH para se conectar a instancia do systemd.

Analisando o estado do sistema

Lista as unidades em execução:

$ systemctl

ou:

$ systemctl list-units

Lista as unidades com erro:

$ systemctl --failed

Os arquivos unidades disponíveis podem ser vistos nos diretórios /usr/lib/systemd/system/ e /etc/systemd/system/ (este último tem precedência). Pode-se listar quais as unidades instalados com:

$ systemctl list-unit-files

Usando Unidades

Unidades podem ser, por exemplo, serviços (.service), pontos de montagem (.mount), dispositivos (.device) ou sockets (.socket).

Quando usar o systemctl, Deve-se geralmente especificar o nome completo do arquivo unidade, incluindo seu sufixo, por exemplo sshd.socket. porém existem algumas excessões:

Se não for especificado o sufixo do arquivo unidade, o systemctl irá entender que se trata de um .service. por exemplo, netcfg e netcfg.service serão tratados de forma equivalente.
Nota: Atualmente esta forma não irá funcionar para os parametros enable e disable.
Pontos de montagem serão automaticamente traduzidos para .mount. por exemplo, especificar /home é equivalente a home.mount.
Igualmente aos pontos de montagem, dispositivos serão automaticamente traduzidos ao seu .device especifico, passando o argumento /dev/sda2 é o mesmo que dev-sda2.device.

Veja man systemd.unit para detalhes.

Ativar uma unidade imediamente:

# systemctl start <unit>

Desativar uma unidade imediatamente:

# systemctl stop <unit>

Reiniciar uma unidade:

# systemctl restart <unit>

Solicitar recarregar a unidade:

# systemctl reload <unit>

Exibe o status da unidade, incluindo se está em execução ou não:

$ systemctl status <unit>

Verificar se a unidade está habilitada ou não:

$ systemctl is-enabled <unit>

Habilitar o início da unidade na inicialização:

# systemctl enable <unit>

Nota: Se o serviço não contiver uma seção Install, geralmente significa que será chamado por outro serviço automaticamente. Se for preciso, terá que instalar o serviço manualmente com o seguinte comando, substituindo foo pelo nome do serviço correspondente:

# ln -s /usr/lib/systemd/system/foo.service /etc/systemd/system/graphical.target.wants/

Desabilita a unidade na inicialização:

# systemctl disable <unit>

Exibe o manual da unidade (Deve ser suportado pelo arquivo unidade):

$ systemctl help <unit>

Gerenciamento de energia

Se você estiver em uma sessão local do systemd-logind ou ConsoleKit e não houver nenhuma outra sessão ativa, os comandos a seguir funcionaram sem a necessidade de privilégios de administrador, se não (por exemplo, outro usuário logado em alguma tty), o systemd irá requisitar automaticamente a senha do root (veja também Substituindo o ConsoleKit pelo systemd-logind).

Reinicia o sistema:

$ systemctl reboot

Desliga o sistema:

$ systemctl poweroff

Dica: Veja man halt para descobrir a diferença entre halt e poweroff

Para o sistema:

$ systemctl halt

Suspende o sistema:

$ systemctl suspend

Hiberna o sistema:

$ systemctl hibernate