Como outros já observaram aqui, em teoria, isso não deve afetar o usuário final não técnico - e, em teoria, não há diferença entre teoria e prática, mas na prática existe.
Esclarecimento
Acho que poucas coisas postadas aqui precisam de esclarecimento:
É um sistema init, não algo com o qual os usuários tradicionalmente interagem.
Foi o caso do SysV init e do Upstart, mas não é mais o caso do systemd. Ele faz muito de coisas com as quais os usuários tradicionalmente interagem:
Deve substituir completamente a funcionalidade fornecida pelo Upstart
- e fazer algumas coisas extras
Duas coisas para esclarecer - primeiro sobre a substituição completa do Upstart:
Não há scripts de inicialização do SysV
Um dos problemas que as pessoas têm com o systemd é que ele não executa scripts de inicialização do SysV. Então, há um exemplo que não substitui completamente a funcionalidade fornecida pelo Upstart.
Isso é algo em que poderíamos confiar por mais de 30 anos e tradicionalmente você escreveu scripts de init SysV para máxima portabilidade sem se repetir (escrevendo várias versões dos mesmos scripts), o que não é mais o caso.
Isso não deve ser um problema ao usar somente pacotes de repositórios oficiais, porque presumivelmente todos os pacotes que costumavam ter scripts SysV init ou Upstart precisariam ter seus scripts reescritos antes de serem empacotados.
Será apenas um problema para as pessoas que usarem softwares de terceiros ou personalizados que tenham seus scripts de inicialização escritos para o SysV init ou para o Upstart, e eles precisarão que os scripts de inicialização sejam reconfigurados antes de atualizar para um sistema com systemd (ou obtenha o upstart instalado, que é também uma opção , ou migre para um sistema que não o faça t use systemd).
Existe o systemd-sysv-generator que deve traduzir automaticamente os scripts init do SysV para os scripts do systemd, mas existem alguns bugs e uma longa lista de incompatibilidades explícitas .
Agora, o segundo esclarecimento - sobre essas poucas coisas extras:
Algumas coisas extras
Essas "poucas coisas extras" que o systemd vai cobrir - de acordo com Uma Perspectiva para o systemd - O Que Foi Realizado e o Que Mentiras à frente apresentação
por Lennart Poettering em 2014 no GNOME.asia - são os seguintes:
- sistema init
- registro de diário
- gerenciamento de login
- gerenciamento de dispositivos
- gerenciamento de arquivos temporários e voláteis
- registro de formato binário
- luz de fundo salvar / restaurar
- rfkill salvar / restaurar
- bootchart
- readahead
- configuração de armazenamento criptografado
- Descoberta da partição EFI / GPT
- registro de máquina virtual / contêiner
- gerenciamento de contêiner
- gerenciamento de nome de host
- gerenciamento de localidade
- gerenciamento de tempo
- gerenciamento aleatório de sementes
- gerenciamento de variáveis sysctl
- gerenciamento de console
- introspecção
- descoberta automática
- plug and play
- gerenciamento de rede
- systemd-networkd
- cache DNS
- Resposta do mDNS
- Respondente LLMNR
- Verificação DNSSEC
- IPC no kernel
- kdbus
- sd-bus
- sincronização de horário com o NTP
- systemd-timesyncd
- integração com contêineres
- sandbox de serviços
- sandbox de aplicativos
- formato de imagem do SO
- Formato de imagem do contêiner
- Formato de imagem do aplicativo
- GPT com detecção automática
- Sistemas sem estado
- sistemas instanciáveis
- redefinição de fábrica
- inicialização de nós e atualizações
- integração com a nuvem
- gerenciamento de serviços nos nós
- imagens do SO verificáveis até o firmware
- Carregamento de inicialização
- Construindo o sistema operacional de próxima geração da Internet Unificando diferenças sem sentido entre distribuições
Voltando a: "É um sistema init, não algo com o qual os usuários tradicionalmente interagem." - deve ser salientado que o sistema init é apenas um item dessa lista.
E finalmente, a última coisa que gostaria de comentar:
[T] ele só tem tempo que um usuário não técnico verá quando é errado.
Oh, que alívio.:)
Alterações
As alterações mais notáveis para os usuários finais (além dos próprios scripts) são iniciar e interromper serviços e usar comandos como:
que não funciona mais como esperado. Por exemplo, nohup é um comando POSIX para garantir que o processo continue em execução depois que você efetuar logout da sua sessão. não funciona mais no systemd. Também programas como screen e tmux precisam ser invocada de forma especial ou de outra maneira os processos que você executa com eles serão mortos (enquanto não obter esses processos mortos é geralmente o principal motivo de execução de tela ou tmux em primeiro lugar). / p>
Isso não é um bug, é uma opção de design, por isso não é provável que seja consertado no futuro. Isto é o que Lennart Poettering disse sobre esse problema:
Na minha opinião, era realmente estranho do UNIX que, por padrão, deixasse o código arbitrário do usuário permanecer irrestrito após o logout. Ele tem sido discutido há tempos entre muitas pessoas do sistema operacional, que isso deve ser possível, mas certamente não é o padrão, mas ninguém ousou mudar o controle para transformá-lo de padrão em opção. Não limpar as sessões do usuário após o logout não é apenas feio e um pouco agressivo, mas também um problema de segurança. O systemd 230 agora finalmente acionou o switch e finalmente, por padrão, limpa tudo corretamente quando o usuário efetua logout.
Para mais informações, consulte:
executando screen
-
upstart:
screen
-
systemd:
systemd-run --user --scope screen
(Nota: o comportamento de "upstart" acima é realmente qualquer coisa, exceto o systemd, isso não é específico do upstart)
Iniciando o trabalho foo:
-
upstart:
start foo
-
systemd:
systemctl start foo
Parando o trabalho foo:
-
upstart:
stop foo
-
systemd:
systemctl stop foo
Reiniciando o trabalho foo:
-
upstart:
restart foo
-
systemd:
systemctl restart foo
Como listar trabalhos com o status deles:
-
upstart:
initctl list
-
systemd:
systemctl status
(Veja a minha resposta para Quais são os prós / contras do Upstart e systemd? para mais detalhes que estão fora do escopo desta questão.
Registros
Há também uma grande diferença no manuseio dos logs, porque, ao contrário da tradição do Unix, os logs do systemd são armazenados em arquivos binários em um formato personalizado, portanto, em vez de:
cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log
você precisa usar comandos especiais para acessar seus registros:
sudo journalctl -u foo
sudo journalctl -u foo -f
Controvérsias
A introdução do systemd primeiro ao Debian e depois ao Ubuntu não foi isenta de controvérsias e vasta oposição como é sabido por qualquer um que escreveu um dos seguintes artigos:
A posição oficial do Debian no systemd e o resultado levou à declaração do Êxodo em 2014 e terminou com Renúncia de Ian Jackson .
A Liberdade de Iniciação , Without-Systemd.org e Systemd-Free.org .
Leitura adicional