Atualização de 2016
A maioria das respostas aqui tem cinco anos, então é hora de fazer algumas atualizações.
O Ubuntu costumava usar o upstart por padrão, mas eles o abandonaram no ano passado em favor do systemd - veja:
Por isso, há um belo artigo Systemd para usuários iniciantes no wiki do Ubuntu - comparação muito detalhada entre upstart e systemd e um guia de transição de iniciante para systemd.
(Observe que, de acordo com o wiki do Ubuntu, você ainda pode executar o startstart nas versões atuais do Ubuntu por padrão instalando upstart-sysve executando, sudo update-initramfs -umas considerando o escopo do projeto systemd, não sei como ele funciona na prática, ou se o systemd está ou não possível desinstalar.)
A maioria das informações nas seções de Comandos e Scripts abaixo é adaptada de alguns dos exemplos usados nesse artigo (que é convenientemente licenciado como as contribuições dos usuários do Stack Exchange sob a Licença Creative Commons Attribution-ShareAlike 3.0 ).
Aqui está uma rápida comparação de comandos comuns e scripts simples, consulte as seções abaixo para obter uma explicação detalhada. Esta resposta está comparando o comportamento antigo dos sistemas baseados no Upstart com o novo comportamento dos sistemas baseados no systemd, conforme solicitado na pergunta, mas observe que os comandos marcados como "Upstart" não são necessariamente específicos do Upstart - geralmente são comandos que são comuns a todos os sistemas Linux e Unix que não são do sistema.
Comandos
Executando su:
- subir na vida:
su
- systemd:
machinectl shell
(consulte a seção "substituição de comando su" abaixo)
Tela de corrida:
- subir na vida:
screen
- systemd:
systemd-run --user --scope screen
(consulte a seção "Eliminação inesperada de processos em segundo plano" abaixo)
Executando o tmux:
- subir na vida:
tmux
- systemd:
systemd-run --user --scope tmux
(consulte a seção "Eliminação inesperada de processos em segundo plano" abaixo)
Iniciando o trabalho foo:
- subir na vida:
start foo
- systemd:
systemctl start foo
Parando o trabalho foo:
- subir na vida:
stop foo
- systemd:
systemctl stop foo
Reiniciando o trabalho foo:
- subir na vida:
restart foo
- systemd:
systemctl restart foo
Listagem de trabalhos:
- subir na vida:
initctl list
- systemd:
systemctl status
Verificando a configuração do trabalho foo:
- subir na vida:
init-checkconf /etc/init/foo.conf
- systemd:
systemd-analyze verify /lib/systemd/system/foo.service
Listando as variáveis de ambiente do trabalho:
- subir na vida:
initctl list-env
- systemd:
systemctl show-environment
Configurando a variável de ambiente do trabalho:
- subir na vida:
initctl set-env foo=bar
- systemd:
systemctl set-environment foo=bar
Removendo a variável de ambiente do trabalho:
- subir na vida:
initctl unset-env foo
- systemd:
systemctl unset-environment foo
Logs
No início, os logs são arquivos de texto normais no diretório / var / log / upstart, para que você possa processá-los normalmente:
cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log
No systemd, os logs são armazenados em um formato binário interno (não como arquivos de texto), portanto, você precisa usar o journalctlcomando para acessá-los:
sudo journalctl -u foo
sudo journalctl -u foo -f
Scripts
Exemplo de script inicial, escrito em /etc/init/foo.conf:
description "Job that runs the foo daemon"
start on runlevel [2345]
stop on runlevel [016]
env statedir=/var/cache/foo
pre-start exec mkdir -p $statedir
exec /usr/bin/foo-daemon --arg1 "hello world" --statedir $statedir
Exemplo de script systemd escrito em /lib/systemd/system/foo.service:
[Unit]
Description=Job that runs the foo daemon
Documentation=man:foo(1)
[Service]
Type=forking
Environment=statedir=/var/cache/foo
ExecStartPre=/usr/bin/mkdir -p ${statedir}
ExecStart=/usr/bin/foo-daemon --arg1 "hello world" --statedir ${statedir}
[Install]
WantedBy=multi-user.target
substituição de comando su
Uma susubstituição de comando foi mesclada no systemd na solicitação pull 1022:
porque, de acordo com Lennart Poettering, "su é realmente um conceito quebrado" .
Ele explica que "você pode usar su e sudo como antes, mas não espere que funcione completamente " .
A maneira oficial de obter um sucomportamento semelhante é agora:
machinectl shell
Foi explicado ainda mais
por Lennart Poettering
na discussão da edição 825:
"Bem, houve longas discussões sobre isso, mas o problema é que o que su deve fazer é muito claro. [...] Resumindo a história: su é realmente um conceito quebrado. Ele fornecerá uma espécie de casca , e é bom usá-lo para isso, mas não é um login completo e não deve ser confundido com um. " - Lennart Poettering
Veja também:
Matança inesperada de processos em segundo plano
Comandos como:
não funciona 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 eliminados (embora a não eliminação desses processos seja geralmente o principal motivo da execução do screen ou tmux, em primeiro lugar).
Isso não é um erro, é uma decisão deliberada, 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 para o 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 de SO, que isso deve ser possível, mas certamente não é o padrão, mas ninguém se atreveu até agora a mudar o interruptor para transformá-lo de um padrão em 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:
Conceito de inicialização de alto nível
De certa forma, o systemd funciona ao contrário - nos trabalhos iniciados, o mais rápido possível, e no systemd, quando necessário. No final do dia, os mesmos trabalhos podem ser iniciados pelos dois sistemas e praticamente na mesma ordem, mas você pensa nisso olhando de uma direção oposta, por assim dizer.
Aqui está como o Systemd for Upstart Users explica:
Upstart modelo 's para iniciar processos (empregos) é 'ganancioso evento-based', empregos ou seja, todos disponíveis cujos eventos de inicialização acontecer são iniciados tão cedo quanto possível. Durante a inicialização, o upstart sintetiza alguns eventos iniciais, como inicialização ou rcS, como a "raiz da árvore", os serviços iniciais iniciam nesses e os serviços posteriores são iniciados quando os primeiros estão em execução. Um novo trabalho apenas precisa instalar seu arquivo de configuração no / etc / init / para se tornar ativo.
O modelo do systemd para iniciar processos (unidades) é "baseado na dependência lenta", ou seja, uma unidade será iniciada apenas se e quando alguma outra unidade inicial depender dela. Durante a inicialização, o systemd inicia uma "unidade raiz" (default.target, pode ser substituída no grub), que então se expande transitivamente e inicia suas dependências. Uma nova unidade precisa se adicionar como uma dependência da unidade da sequência de inicialização (geralmente multiusuário.target) para se tornar ativa.
Uso em distribuições
Agora, alguns dados recentes, de acordo com a Wikipedia:
Distribuições usando upstart por padrão:
Distribuições usando systemd por padrão:
(Veja Wikipedia para informações atualizadas)
Distribuições usando nem Upstart nem systemd:
Controvérsia
No passado, um fork do Debian foi proposto para evitar o systemd . O Devuan GNU + Linux foi criado - uma bifurcação do Debian sem systemd (obrigado a fpmurphy1 por apontá-lo nos comentários).
Para mais informações sobre essa controvérsia, consulte:
Como muitos de vocês já devem saber, o voto do Init GR Debian promovido por Ian Jackson não foi útil para proteger o legado do Debian e seus usuários da avalanche do sistema.
Esta situação prevê um bloqueio nas dependências do sistema, o que está de fato ameaçando a liberdade de desenvolvimento e tem sérias conseqüências para o Debian, seu upstream e downstream.
O CTTE conseguiu trocar uma dependência e ganhar tempo com uma instalação sutil do systemd sobre o sysvinit, mas mesmo esse processo foi exaustivo e cheio de drama. Por fim, há uma semana, Ian Jackson renunciou. [...]
Estou renunciando ao Comitê Técnico com efeito imediato.
Embora seja importante que as visões dos 30-40% do projeto que concordam comigo continuem sendo representadas no CT, eu mesmo sou claramente uma figura controversa demais neste momento. Devo me afastar para tentar reduzir em que medida as conversas sobre a governança do projeto são personalizadas. [...]
O Devuan nasceu de uma controvérsia sobre a decisão de usar como o sistema init padrão para o Debian. A posição oficial do Debian no systemd está cheia de reivindicações que outros desmascararam . Os leitores interessados podem continuar discutindo esse tópico importante em A controvérsia do sistema . No entanto, recomendamos que você mantenha a cabeça fria e a voz civilizada. Na Devuan, estamos mais interessados em programá-los de maneira errada do que olhar para trás. [...]
Alguns sites e artigos dedicados à controvérsia do systemd foram criados:
Há muitas discussões interessantes sobre o Hacker News:
Tendências semelhantes em outras distros também podem ser observadas:
Filosofia
O iniciante segue a filosofia Unix de DOTADIW - "Faça uma coisa e faça bem". É um substituto para o daemon init tradicional. Ele não faz nada além de iniciar e parar serviços. Outras tarefas são delegadas a outros subsistemas especializados.
O systemd faz muito mais que isso. Além de iniciar e interromper os serviços, ele também gerencia senhas, logins, terminais, gerenciamento de energia, redefinições de fábrica, processamento de log, pontos de montagem do sistema de arquivos, rede e muito mais - consulte o arquivo NEWS para alguns dos recursos.
Planos de expansão
De acordo com A Perspective para systemd O que foi alcançado e a apresentação de Lennart Poettering em 2014 no GNOME.asia, aqui estão os principais objetivos do systemd, áreas que já foram cobertas e que ainda estavam em andamento:
objetivos do sistema:
Nossos objetivos
- Transformando o Linux de um pacote de bits em um sistema operacional de uso geral competitivo.
- Construindo o sistema operacional de próxima geração da Internet Unificando diferenças sem sentido entre distribuições
Trazendo a inovação de volta ao SO principal
Desktop, Servidor, Contêiner, Incorporado, Móvel, Nuvem, Cluster,. . . Essas áreas estão mais próximas do que você imagina
- Reduzindo a complexidade do administrador, a confiabilidade sem supervisão
- Tudo introspectável
- A descoberta automática, plug and play é fundamental
- Nós consertamos as coisas onde elas estão quebradas, nunca as colamos
Áreas já cobertas:
O que já cobrimos:
sistema init, registro em diário, gerenciamento de logon, gerenciamento de dispositivos, gerenciamento de arquivos temporários e voláteis, registro de formato binário, salvamento / restauração de luz de fundo, salvamento / restauração de rfkill, bootchart, readahead, configuração de armazenamento criptografado, descoberta de partição EFI / GPT, máquina virtual / contêiner registro, gerenciamento mínimo 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,. . .
Trabalho em progresso:
No que estamos trabalhando:
- Gerenciamento de rede
- systemd-networkd
- Cache DNS local, respondedor mDNS, respondedor LLMNR, verificação DNSSEC
- IPC no kernel
- kdbus, sd-bus
- Sincronização de tempo com NTP
- systemd-timesyncd
- Maior 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 da aplicação
- GPT com descoberta automática
- Sistemas sem estado, sistemas instantâneos, redefinição de fábrica
- / usr é o sistema operacional
- / etc é (opcional) configuração
- / var é o estado (opcional)
- Inicialização e atualizações do nó atômico
- Integração com a nuvem
- Gerenciamento de serviço entre nós
- Imagens verificáveis do SO
- Todo o caminho até o firmware
- Carregamento de inicialização
Escopo desta resposta
Como fpmurphy1 observou nos comentários, "Deve-se ressaltar que o systemd expandiu seu escopo de trabalho ao longo dos anos muito além do simples início de inicialização do sistema".
Tentei incluir a maioria das informações relevantes aqui. Aqui, estou comparando os recursos comuns do Upstart e systemd quando usados como sistemas init, conforme solicitado na pergunta, e mencionei apenas os recursos do systemd que vão além do escopo de um sistema init porque eles não podem ser comparados ao Startup, mas sua presença é importante para entender a diferença entre esses dois projetos. A documentação relevante deve ser verificada para mais informações.
Mais informações
Mais informações podem ser encontradas em:
Extras
A equipe do LinOxide criou uma folha de dicas do Systemd vs SysV Init Linux .