A maior mudança que vem com o Ubuntu 15.04 é a mudança do iniciante para o systemd como o padrão para gerenciar a inicialização dos serviços de sistema e inicialização.
Alguém poderia explicar adequadamente a um usuário não técnico como e se isso nos afeta? E porque é importante?
Respostas:
Usuários leigos não devem notar nenhuma alteração, por padrão. É um sistema init, não algo com o qual os usuários interagem tradicionalmente. Ele deve substituir completamente a funcionalidade fornecida pelo Upstart - e fazer algumas coisas extras - mas a única vez que um usuário não técnico verá isso é quando ocorrer um erro.
Usuários, administradores de sistemas e desenvolvedores que estão usando e desenvolvendo ativamente o Upstart são as pessoas que precisam resolver os problemas. Há um documento de migração no Ubuntu Wiki para ajudar os desenvolvedores a converter seus scripts init, mas usuários e sistemas podem continuar usando o Upstart usando a versão 14.04 (que é suportada até 2019).
A razão e a justificativa da 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 mudar para um mecanismo init moderno para obter melhor simultaneidade na inicialização e melhor funcionalidade de monitoramento em todos os serviços.
Isso significou uma briga entre várias opções (as lógicas) e o systemd eventualmente venceu.
A Canonical concordou com o Debian porque é mais fácil e provavelmente o melhor. Eles abandonam um projeto e não estão lutando contra a corrente. Ele também nos alinha a 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 em tudo. Para o Ubuntu, isso significa menos trabalho e um melhor sistema de inicialização.
Alguém poderia explicar adequadamente a um usuário não técnico como e se isso nos afeta?
Em teoria, isso não deve afetar o usuário final não técnico que não se envolve no âmago da questão de como o sistema realmente funciona. Na prática, há muitas coisas que você verá.
Aqui está uma lista incompleta:
init+ rcsão mordidos pelo fato de que systemd é compatível apenas com versões anteriores do Sistema 5 rc. Como o iniciante e, na verdade, a maioria dos outros sistemas, ele professa e fornece, sem compatibilidade com o System 5 inite seu arquivo de configuração /etc/inittab.Então, as pessoas que seguiram o conselho dos 30 anos de aconselhamento "Bem, você pode simplesmente editar isso em /etc/inittab...", ou as pessoas que usam softwares que seguiram esse conselho agora têm softwares que não iniciam no bootstrap. Exemplo: https://unix.stackexchange.com/a/196197/5132
shutdowncomando systemd , como poderia com os shutdowncomandos anteriores . Além do fato de ser 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 nowdesligará a máquina. É systemctl rescuealcançar o modo de usuário único no mundo systemd. Leitura adicional: https://unix.stackexchange.com/a/196471/5132--useropção systemctl. Isso não se aplica ao Ubuntu (ainda). upstart e systemd diferem significativamente nessa área, e a versão 15 do Ubuntu ainda usa o init upstart por sessão em vez de uma instância systemd por usuário . Portanto, https://superuser.com/a/860598/38062 não se aplicará, por exemplo. ☺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.
Acho que poucas coisas postadas aqui precisam de alguns esclarecimentos:
É um sistema init, não algo com o qual os usuários interagem tradicionalmente.
Foi o caso do SysV init e do Upstart, mas não é mais o caso do systemd. Ele faz muitas coisas com as quais os usuários tradicionalmente interagem:
Ele deve substituir completamente a funcionalidade fornecida pelo Upstart - e fazer algumas coisas extras
Duas coisas a esclarecer - primeiro sobre a substituição completa do Upstart:
Um dos problemas que as pessoas têm com o systemd é que ele não executa scripts de inicialização do SysV. Portanto, há um exemplo de que ele não substitui completamente a funcionalidade fornecida pelo Upstart.
Isso é algo em que podemos confiar há mais de 30 anos e, tradicionalmente, você escrevia scripts init do SysV para portabilidade máxima 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 apenas 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 usam qualquer software personalizado ou de terceiros que tenha seus scripts init escritos para o SysV init ou para o Upstart e esses precisarão dos scripts init reescritos antes de atualizar para um sistema com systemd (ou obter o iniciante instalado, que também é uma opção , ou migra para um sistema que não usa systemd).
Há systemd-sysv-generator que deve converter automaticamente scripts de inicialização do SysV em scripts de systemd, mas existem alguns erros e uma longa lista de incompatibilidades explícitas .
Agora, o segundo esclarecimento - sobre essas poucas coisas extras:
Essas "poucas coisas extras" que o systemd abordará - de acordo com A Perspective para systemd - O que foi alcançado e o que está por vir apresentado por Lennart Poettering em 2014 no GNOME.asia - são as seguintes:
Voltando a: "É um sistema init, não algo com o qual os usuários interagem tradicionalmente". - é preciso salientar que o sistema init é apenas um item dessa lista.
E, finalmente, a última coisa que gostaria de comentar:
[A] única vez em que um usuário não técnico verá isso é quando algo der errado.
Oh, que alívio! :)
As alterações mais notáveis para usuários finais (que não sejam os próprios scripts) estão iniciando e parando serviços e usando comandos como:
que não funcionam mais como o esperado. Por exemplo, nohupé um comando POSIX para garantir que o processo continue em execução após o logout da sessão. Já não funciona no systemd. Também programas como screene tmuxprecisam ser invocados de uma maneira especial ou, caso contrário, os processos que você executa com eles serão mortos (apesar de não serem mortos nesses processos, geralmente é o principal motivo da execução do screen ou tmux em primeiro lugar).
Isso não é um bug, é uma escolha de design, portanto, não é provável que seja corrigido no futuro. Foi o que Lennart Poettering disse sobre esse assunto:
Na minha opinião, era realmente muito estranho no UNIX que, por padrão, deixasse o código arbitrário do usuário ficar irrestrito após o logout. Foi discutido há muito tempo entre muitas pessoas do sistema operacional, que isso deve ser possível, mas certamente não é o padrão, mas ninguém se atreveu até o momento a acionar o comutador para passar de um padrão para uma opção. Não limpar as sessões do usuário após o logout não é apenas feio e um tanto burro, mas também um problema de segurança. O systemd 230 agora finalmente apertou o botão e finalmente, por padrão, limpa tudo corretamente quando o usuário efetua logout.
Para mais informações, consulte:
screenscreensystemd-run --user --scope screen(Nota: o comportamento do "iniciante" acima é realmente qualquer coisa, exceto systemd, isso não é específico do inicio)
start foosystemctl start foostop foosystemctl stop foorestart foosystemctl restart fooinitctl listsystemctl status(Veja minha resposta em Quais são os prós / contras do Upstart e do systemd? Para obter mais detalhes que estão fora do escopo desta pergunta.)
Há também uma grande diferença no manuseio dos logs, porque, contrariamente à 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 logs:
sudo journalctl -u foo
sudo journalctl -u foo -f
A introdução do systemd primeiro no Debian e depois no Ubuntu não foi isenta de controvérsias e vasta oposição, como é conhecido por quem escreveu um dos seguintes artigos:
A posição oficial do Debian no systemd e a controvérsia resultante levaram à declaração do Êxodo em 2014 e terminaram com a renúncia de Ian Jackson .
O Freedom Init , Without-Systemd.org e Systemd-Free.org iniciativas nasceram, com um monte de discussão sobre Hacker News .