1.) multi-user.targeté basicamente o equivalente mais próximo do nível de execução 3 clássico do SysVinit systemd. Quando um systemdsistema é inicializado, systemdestá tentando fazer com que o estado do sistema corresponda ao estado especificado por default.target- que geralmente é um alias para graphical.targetou multi-user.target.

multi-user.targetnormalmente define um estado do sistema onde todos os serviços de rede são iniciados e o sistema aceitará logins, mas uma GUI local não é iniciada. Este é o estado de sistema padrão típico para sistemas de servidor, que podem ser sistemas sem periféricos montados em rack em uma sala de servidores remotos.

graphical.targeté outro alias possível para default.target. Normalmente é definido como um superconjunto do multi-user.target: inclui tudo o multi-user.targetque faz, mais a ativação de um login de GUI local. Assim como o nível de execução 5 no clássico SysVinit.

A linha WantedBy=multi-user.targetem um serviço é essencialmente a mesma que especificar "este serviço deve iniciar nos níveis de execução 3, 4 e 5" em sistemas SysVinit: ela informa systemdque este serviço deve ser iniciado como parte da inicialização normal do sistema, seja ou não um local A GUI está ativa.

No entanto, WantedByé separado do estado ativado/desativado: então, em outro sentido, é uma espécie de "predefinição": determina em que condições o início automático pode ocorrer, mas apenas quando o serviço é ativado em primeiro lugar.

2.) se você omitir a WantedBy=multi-user.targetlinha e nenhum outro serviço habilitado incluir um Requires=your.serviceou Wants=your.serviceem sua definição de serviço, seu serviço não será iniciado automaticamente.

systemdfunciona em dependências e, no momento da inicialização, se nada Requiresou Wantsseu serviço, ele não será iniciado, mesmo que o serviço esteja habilitado.

Claro, você pode editar seu default.targetpara adicionar ou excluir Requiresou Wantslinhas para qualquer serviço que deseja iniciar no momento da inicialização - mas para que você possa simplesmente soltar um novo arquivo de serviço no sistema e fazê-lo funcionar por padrão (o que facilita muito as coisas para o software gerenciadores de pacotes), systemdtem as palavras-chave WantedBye RequiredByque podem ser usadas para inserir Wantse digitar Requiresdependências (respectivamente) do "outro lado".

3.) Você deve omitir a linha se não quiser que o serviço seja iniciado automaticamente no momento da inicialização ou se esse serviço for parte de uma cadeia de dependências que você definiu explicitamente.

Por exemplo, você pode estar refatorando o aplicativo de servidor A e, por algum motivo ou outro, decidir dividir alguma funcionalidade opcional dele em um serviço B separado, para permitir ao usuário a opção de não instalá-lo se não for necessário. Você pode então tornar o serviço B um separado service-B.rpme definir B.servicecom WantedBy=A.servicepara fazer systemdo serviço B inicializar automaticamente sempre que o serviço A for iniciado - mas somente quando service-B.rpmestiver realmente instalado.

Observe que a Wantsou WantedByapenas diz que o sistema deve inicializar um serviço sempre que outro serviço ou destino também for iniciado, mas não especifica nada sobre a ordem de inicialização/desligamento. Se você precisar que o serviço B já esteja em execução quando o serviço A for inicializado, será necessário adicionar Before=A.serviceo B.servicearquivo para especificar explicitamente a dependência da ordem de inicialização.

4.) Sempre que você quiser que o serviço tenha a capacidade de ser iniciado automaticamente no momento da inicialização, e não houver outras dependências já definidas.

Se você remover WantedBy=multi-user.target, então systemctl enable your-example-here(ruidosamente) não fará nada.

gráfico.destino

Se você instalar o systemd puro a partir da origem, o "destino padrão" no qual ele inicializará será graphical.target.

Iniciando graphical.targetinicia multi-user.target, mais qualquer unidade(s) necessária(s) para fornecer uma interface gráfica de usuário. Essa complexidade extra foi organizada em uma tentativa de emular "runlevels" herdados.

Você realmente deve ignorar / ignorar a emulação "runlevel"; ele não funciona corretamente de qualquer maneira. Desculpe! Eu acho que a razão para enfatizar "gráfico" versus "multiusuário" historicamente é que o software gráfico é 1) não tão robusto e maduro quanto o resto do sistema e 2) requer muitos recursos.

Normalmente, apenas algumas unidades são específicas para graphical.target. Existe um único serviço para a própria GUI, como gdm.target. Existem alguns serviços de suporte que são usados ​​principalmente pela GUI aqui também.

Editar: A pesquisa no Google sugere que, se você não tiver uma GUI instalada, mas o "destino padrão" tiver sido deixado como graphical.target, o systemd poderá registrar um aviso. "Não é possível adicionar trabalho de dependência para unidade display-manager.service, ignorando: Unidade display-manager.service falhou ao carregar: Arquivo ou diretório inexistente." Queremos evitar sujar nossos logs com avisos desnecessários. Portanto, se você não instalou uma GUI, é bom usar o systemctl set-default multi-user. Embora o sistema de instalação do seu sistema operacional já tenha cuidado disso para você. Fora isso, sou fortemente a favor da apatia neste assunto :-).

sysinit.target

Alguns serviços e outros tipos de unidades estão "envolvidos na inicialização antecipada". Eles são definidos para iniciar Before=sysinit.target- direta ou indiretamente. A maioria dos serviços é iniciada apenas After=sysinit.target- esse é o caso automaticamente, a menos que o serviço defina DefaultDependencies=no.

multiusuário.destino

A maioria dos serviços de exemplo não se enquadra em nenhuma das categorias acima, portanto, os anexamos a multi-user.target. Isso inclui a maioria dos serviços de rede (por exemplo, um servidor web), que são o serviço de sistema arquetípico.

serviços ativados dinamicamente

Outra possibilidade que você pode ver é uma unidade de serviço que não é iniciada automaticamente na inicialização. Então não precisaria WantedBy=multi-user.target. O serviço pode ser acionado ou "ativado" por outra coisa.

Um exemplo disso é um serviço ativado por dbus. O Dbus pode ser configurado para iniciar seu serviço sob demanda, quando uma chamada dbus é feita ao serviço.

Para serviços de rede, você pode usar serviços ativados por soquete. Isso pode ser mais fácil de encontrar detalhes, porque toda a configuração está em unidades systemd. Por exemplo , sshd.socketou ssh.socketnormalmente está disponível para ativar [email protected]ou [email protected]. Embora eu ache mais comum iniciar o serviço sshd no momento da inicialização.

Como sempre, o acima simplifica e omite detalhes que não pareciam ser necessários.

O multi-user.targeté um nome semântico, ou seja, está associado a um significado. Permita-me demonstrar o conceito com um contra-exemplo. Vou argumentar que a decisão de usar multi-user.targetdepende do contexto.

Se você criasse uma configuração de unidade de usuário systemd em vez de uma configuração de unidade de sistema , você poderia ingenuamente seguir as convenções das unidades de sistema systemd e usar multi-user.target¹ .

Explicação por Contra-Exemplo

Considere o arquivo/home/jonathan/.config/systemd/user/coolstuff.service

Esse usuário será usado apenas em relação a user jonathan, portanto, dificilmente faz sentido chamar meu destino de "multi-user.target".

[Unit]
Description=Does some cool stuff.

[Service]
ExecStart=/bin/bash -c '/usr/bin/echo "Cool stuff" >> %h/coolstuff.txt'

[Install]
WantedBy=user.target

Observe como optei por usar WantedBy=user.target . Isso porque o escopo desse contexto é minha conta de usuário, portanto optei por usar minhas próprias convenções semânticas. Em outras palavras, vários usuários não serão afetados por esta unidade. No nível do sistema, no entanto, faz mais sentido seguir convenções padronizadas devido à sequência de inicialização paralela. Durante a inicialização, muitos procedimentos convergem em vários destinos. O multi-user.targetestá semanticamente associado à ideia de "ler para engajamento do usuário / interação com o sistema" (sem um sistema de janelas como o telcoM mencionado), portanto, é uma aposta segura para a maioria dos arquivos de unidade do sistema.

Notas de rodapé

1. Embora não fizesse sentido dentro desse contexto, ainda funcionaria.