Justificativa para mudar de upstart para systemd?

27

A mudança maior que vem com o Ubuntu 15.04 é a mudança do upstart para o systemd como o padrão para gerenciar inicialização e inicialização do serviço do sistema.

Alguém poderia explicar adequadamente a um usuário não técnico como e se isso afeta a todos nós? E por que isso é importante?

    
por Nikos Grigoriadis 24.04.2015 / 15:20

3 respostas

27

Os usuários do Layman não devem notar nenhuma alteração, por design. É um sistema init, não é algo que os usuários tradicionalmente interagem. Ele deve substituir completamente a funcionalidade oferecida pelo Upstart - e fazer algumas coisas extras -, mas a única vez que um usuário não técnico irá ver é quando isso dá errado.

Usuários, administradores de sistemas e desenvolvedores que têm usado e desenvolvendo ativamente para o Upstart são as pessoas que precisam lidar com as coisas. Há um documento de migração no Ubuntu Wiki para ajudar os desenvolvedores a converter seus scripts de init, mas usuários e sysops podem continuar usando o Upstart aderindo com 14.04 (que é suportado até 2019).

O motivo e a justificativa para a mudança realmente não eram do lado do Ubuntu. A Canonical estava feliz o suficiente com o Upstart (seu projeto), mas muitos usuários do Debian queriam migrar para um mecanismo de inicialização moderno para obter uma melhor concorrência na inicialização e melhor funcionalidade de monitoramento em todos os serviços.

Isso significava uma briga entre várias opções (as justificativas) e o systemd acabou ganhando.

A Canonical concordou com o Debian porque é mais fácil e provavelmente melhor. Eles conseguem abandonar um projeto e não estão lutando contra o fluxo. Também nos coloca em sintonia com outras distribuições (Red Hat, Fedora, etc) que também estão migrando para o systemd. Mais foco e menos duplicação de esforços.

tl; dr Para uma pessoa não técnica, isso não deve afetá-lo. Para o Ubuntu, isso deve significar menos trabalho e um melhor sistema de inicialização.

    
por Oli 24.04.2015 / 16:30
15
  

Alguém poderia explicar adequadamente a um usuário não técnico como e se isso afeta a todos nós?

Em teoria, isso não deve afetar o usuário final não-técnico que não se envolve com o âmago da questão de como o sistema realmente funciona. Na prática, há muitas coisas que você verá.

Aqui está uma lista incompleta:

  • Se você tivesse softwares complementares que usassem arquivos de definição de tarefa para iniciar programas, eles parariam de funcionar. Você terá que instalar (e possivelmente gravar, mas mais comumente apenas apagar alguém que já tenha escrito) arquivos systemd unidade de serviço . Exemplo: Ссылка
  • Várias suposições de design feitas por desenvolvedores do systemd sobre coisas como gerenciamento de energia resultam em padrões que estão em desacordo com o que você pode estar acostumado. Os desenvolvedores do systemd têm ideias muito definidas sobre o que deve acontecer em resposta às mudanças na tampa dos laptops , por exemplo.
  • Se você estiver usando o driver de vídeo proprietário da nvidia, existem várias decisões de design no systemd que afetam você. Exemplo: Ссылка
  • Não é relevante quando vem de iniciantes, já que os usuários do Ubuntu têm uma página de manual dizendo isso há alguns anos, mas eu menciono isso para os usuários que não são usuários do Ubuntu que podem ler isto: Outros usuários de sistemas operacionais Linux O sistema 5 init + rc é mordido pelo fato de que systemd é somente compatível com o System 5 rc . Como upstart, e na verdade a maioria dos outros sistemas, professa e fornece, sem compatibilidade com o System 5 init e seu arquivo de configuração /etc/inittab .

    Então, pessoas que seguiram o conselho dos 30 e poucos anos de pessoas aconselhando "Bem, você pode simplesmente editar isso em /etc/inittab …", ou pessoas que usam softwares que seguiram esse conselho agora têm softwares que não iniciam no bootstrap. Exemplo: Ссылка

  • Você não pode acessar o modo de usuário único por meio do comando systemd shutdown , como fazia com os comandos anteriores shutdown . Além do fato de que é chamado de modo de recuperação no jargão do systemd, o modo de recuperação não é considerado um estado de desligamento na visão de mundo do systemd. É considerado como um estado em execução . shutdown now desligará a máquina. É systemctl rescue para alcançar o modo de usuário único no mundo do systemd. Outras leituras: Ссылка
  • Além desse último assunto: se você não tiver jogado fora a idéia de níveis de execução , agora é a hora de fazê-lo. Mais: Ссылка
  • Você terá que ser cuidadoso ao seguir os conselhos gerais do sistema encontrados pela navegação aleatória na WWW, porque você "sabe" que "tudo é systemd agora". Você verá pessoas falando sobre a execução de comandos com a opção --user para systemctl . Isso não se aplica ao Ubuntu (ainda). O upstart e o systemd diferem significativamente nesta área, e a versão 15 do Ubuntu ainda usa o init por sessão, em vez de uma instância por usuário por . Portanto Ссылка não se aplica, por exemplo. ☺
por JdeBP 25.04.2015 / 14:00
6

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

por rsp 15.06.2016 / 15:25