systemd, init - gerenciador de sistema e serviços systemd
SINTAXE
/usr/lib/systemd/systemd [OPÇÕES...]
init [OPÇÕES...]
DESCRIÇÃO
systemd é um gerenciador de sistema e serviços para sistemas operacionais Linux. Quando executado como o primeiro processo durante a inicialização (como PID 1), ele atua como um sistema init que inicia e mantém os serviços do espaço do usuário. Instâncias separadas são iniciadas para os usuários conectados para iniciar seus serviços.
Normalmente, systemd não é invocado diretamente pelo usuário, mas é instalado como o link simbólico /sbin/init e iniciado durante a inicialização. As instâncias do gerenciador de usuário são iniciadas automaticamente por meio do serviço [email protected](5).
Quando executado como uma instância de sistema, systemd interpreta o arquivo de configuração system.conf e os arquivos nos diretórios system.conf.d; quando executado como uma instância de usuário, systemd interpreta o arquivo de configuração user.conf e os arquivos nos diretórios user.conf.d. Consulte systemd-system.conf(5) para obter mais informações.
systemd contém implementações nativas de várias tarefas que precisam ser executadas como parte do processo de inicialização. Por exemplo, ele define o nome do host ou configura o dispositivo de rede de loopback. Ele também configura e monta vários sistemas de arquivos de API, como /sys/, /proc/ e /dev/.
systemd também redefinirá o relógio do sistema durante a inicialização, se parecer que ele está definido incorretamente. Veja a seção "Época do relógio do sistema" abaixo.
Observe que nem todas as interfaces fornecidas por systemd são cobertas pela Interface Portability and Stability Promise[1].
A API D-Bus do systemd é descrita em org.freedesktop.systemd1(5) e org.freedesktop.LogControl1(5).
Os sistemas que invocam systemd em um ambiente de contêiner ou initrd devem implementar as especificações da Interface de Contêiner[2] ou da Interface initrd[3], respectivamente.
UNIDADES
systemd fornece um sistema de dependência entre várias entidades chamadas "unidades" de 11 tipos diferentes. As unidades encapsulam vários objetos que são relevantes para a inicialização do sistema e manutenção. A maioria das unidades é configurada em arquivos de configuração de unidade, cuja sintaxe e conjunto básico de opções são descritos em systemd.unit(5), no entanto, algumas são criadas automaticamente a partir de outros arquivos de configuração, dinamicamente a partir do estado do sistema ou programaticamente em tempo de execução. As unidades podem estar em vários estados, descritos na tabela a seguir. Observe que os vários tipos de unidade podem ter vários subestados adicionais, que são mapeados para os estados de unidade generalizados descritos aqui.
Tabela 1. Estados ATIVO da unidade
┌──────────────┬─────────────────────────────────────┐
│ Estado │ Descrição │
├──────────────┼─────────────────────────────────────┤
│ active │ Iniciado, vinculado, conectado, ..., │
│ │ dependendo do tipo de unidade. │
├──────────────┼─────────────────────────────────────┤
│ inactive │ Parado, não vinculado, desconectado, ..., │
│ │ dependendo do tipo de unidade. │
├──────────────┼─────────────────────────────────────┤
│ failed │ Semelhante a inativo, mas a unidade │
│ │ falhou de alguma forma (o processo │
│ │ retornou um código de erro ao sair, │
│ │ travou, uma operação expirou ou │
│ │ após muitas reinicializações). │
├──────────────┼─────────────────────────────────────┤
│ activating │ Mudando de inativo para ativo. │
├──────────────┼─────────────────────────────────────┤
│ deactivating │ Mudando de ativo para inativo. │
├──────────────┼─────────────────────────────────────┤
│ maintenance │ A unidade está inativa e uma manutenção │
│ │ operação está em andamento. │
├──────────────┼─────────────────────────────────────┤
│ reloading │ A unidade está ativa e está recarregando │
│ │ sua configuração. │
├──────────────┼─────────────────────────────────────┤
│ refreshing │ A unidade está ativa e um novo ponto de montagem é │
│ │ sendo ativado em seu namespace. │
└──────────────┴─────────────────────────────────────┘
Unidades de serviço, que iniciam e controlam daemons e os processos que os compõem. Para
mais detalhes, consulte systemd.service(5).
Unidades de soquete, que encapsulam soquetes de IPC local ou de rede no sistema, úteis para
ativação baseada em soquete. Para detalhes sobre unidades de soquete, consulte systemd.socket(5); para detalhes
sobre ativação baseada em soquete e outras formas de ativação, consulte daemon(7).
As unidades de destino são úteis para agrupar unidades ou fornecer pontos de sincronização bem conhecidos durante
a inicialização, consulte systemd.target(5).
As unidades de dispositivo expõem dispositivos do kernel no systemd e podem ser usadas para implementar a ativação baseada em dispositivos. Para obter detalhes, consulte systemd.device(5).
As unidades de montagem controlam os pontos de montagem no sistema de arquivos, para obter detalhes, consulte systemd.mount(5).
As unidades de montagem automática fornecem recursos de montagem automática, para montagem sob demanda de sistemas de arquivos, bem como para inicialização paralela. Consulte systemd.automount(5).
As unidades de temporizador são úteis para acionar a ativação de outras unidades com base em temporizadores. Você pode encontrar
detalhes em systemd.timer(5).
As unidades de troca são muito semelhantes às unidades de montagem e encapsulam partições de memória de troca ou arquivos do sistema operacional. Elas são descritas em systemd.swap(5).
As unidades de caminho podem ser usadas para ativar outros serviços quando os objetos do sistema de arquivos são alterados ou
modificados. Consulte systemd.path(5).
As unidades de fatia podem ser usadas para agrupar unidades que gerenciam processos do sistema (como unidades de serviço e de escopo) em uma árvore hierárquica para fins de gerenciamento de recursos. Consulte systemd.slice(5).
As unidades de escopo são semelhantes às unidades de serviço, mas gerenciam processos externos em vez de iniciá-los. Consulte systemd.scope(5).
As unidades são nomeadas como seus arquivos de configuração. Algumas unidades têm semântica especial. Uma lista detalhada está disponível em systemd.special(7).
O systemd conhece vários tipos de dependências, incluindo dependências de requisito positivas e negativas (isto é, Requires= e Conflicts=), bem como dependências de ordenação (After= e
Before=). Observação: as dependências de ordenação e de requisito são ortogonais. Se apenas uma dependência de requisito existir entre duas unidades (por exemplo, foo.service requer bar.service), mas nenhuma dependência de ordenação (por exemplo, foo.service após bar.service) e ambas forem solicitadas para iniciar, elas serão iniciadas em paralelo. É um padrão comum que dependências de requisito e de ordenação sejam colocadas entre duas unidades. Observe também que a maioria das dependências são criadas e mantidas implicitamente pelo systemd. Na maioria dos casos, não deve ser necessário declarar dependências adicionais manualmente, no entanto, é possível fazê-lo.
Os programas de aplicação e as unidades (por meio de dependências) podem solicitar alterações de estado das unidades. No systemd, essas solicitações são encapsuladas como "jobs" e mantidas em uma fila de jobs. Os jobs podem ter sucesso ou falhar, a execução deles é ordenada com base nas dependências de ordenação das unidades para as quais foram agendados.
Na inicialização, o systemd ativa a unidade de destino default.target, cuja tarefa é ativar os serviços e outras unidades de inicialização, puxando-os por meio de dependências. Normalmente, o nome da unidade é apenas um alias (link simbólico) para graphical.target (para inicializações totalmente funcionais na interface do usuário) ou multi-user.target (para inicializações apenas de console limitadas para uso em ambientes incorporados ou de servidor, ou similares; um subconjunto de graphical.target). No entanto, cabe ao administrador configurá-lo como um alias para qualquer outra unidade de destino. Consulte systemd.special(7) para obter detalhes sobre essas unidades de destino.
Na primeira inicialização, o systemd habilitará ou desabilitará unidades de acordo com a política predefinida. Consulte systemd.preset(5) e "Semântica da Primeira Inicialização" em machine-id(5).
O systemd mantém apenas um conjunto mínimo de unidades carregadas na memória. Especificamente, as únicas unidades que são mantidas carregadas na memória são aquelas para as quais pelo menos uma das seguintes condições é verdadeira:
Ela está em um estado ativo, ativando, desativando ou com falha (ou seja, em qualquer estado de unidade, exceto "inativo")
Ela tem uma tarefa enfileirada para ela
Ela é uma dependência de pelo menos uma outra unidade que está carregada na memória
Ela tem alguma forma de recurso ainda alocado (por exemplo, uma unidade de serviço que está inativa, mas para a qual um processo ainda está ativo e ignorou o pedido para ser encerrado)
Ela foi fixada na memória programaticamente por uma chamada D-Bus
O systemd carregará automaticamente e implicitamente unidades do disco – caso elas ainda não estejam carregadas – assim que as operações forem solicitadas para elas. Assim, em muitos aspectos, o fato de uma unidade estar carregada ou não é invisível para os clientes. Use systemctl list-units --all para listar de forma abrangente todas as unidades atualmente carregadas. Qualquer unidade para a qual nenhuma das condições acima se aplica é rapidamente descarregada. Observe que, quando uma unidade é descarregada da memória, seus dados de contabilização também são liberados. No entanto, esses dados geralmente não são perdidos, pois um registro de log de journal é gerado declarando os recursos consumidos sempre que uma unidade é desligada.
Os processos que o systemd gera são colocados em grupos de controle Linux individuais, nomeados com o nome da unidade à qual pertencem na hierarquia privada do systemd. (veja Control Groups v2[4] para mais informações sobre grupos de controle, ou, em resumo, "cgroups"). O systemd usa isso para rastrear efetivamente os processos. As informações do grupo de controle são mantidas no kernel e são acessíveis por meio da hierarquia do sistema de arquivos (abaixo de /sys/fs/cgroup/) ou em ferramentas como systemd-cgls(1) ou ps(1) (ps xawf -eo pid,user,cgroup,args é particularmente útil para listar todos os processos e as unidades do systemd às quais pertencem).
O systemd é compatível com várias funcionalidades Unix estabelecidas, como /etc/fstab ou o banco de dados utmp.
O systemd tem um sistema de transação mínimo: se uma unidade for solicitada para iniciar ou desligar, ela a adicionará e todas as suas dependências a uma transação temporária. Em seguida, ele verificará se a transação é consistente (ou seja, se a ordem de todas as unidades é livre de ciclos). Se não for, o systemd tentará corrigi-la e removerá tarefas não essenciais da transação que possam remover o ciclo. Além disso, o systemd tenta suprimir tarefas não essenciais na transação que interromperiam um serviço em execução. Finalmente, é verificado se as tarefas da transação contradizem tarefas que já foram enfileiradas e, opcionalmente, a transação é abortada. Se tudo funcionar e a transação for consistente e minimizada em seu impacto, ela será mesclada com todas as tarefas pendentes e adicionada à fila de execução. De forma eficaz, isso significa que, antes de executar uma operação solicitada, o systemd verificará se ela faz sentido, corrigindo-a se possível e falhando apenas se ela realmente não puder funcionar.
Observe que as transações são geradas independentemente do estado de uma unidade em tempo de execução; portanto, por exemplo, se for solicitado um trabalho de inicialização em uma unidade já iniciada, ainda assim será gerada uma transação e quaisquer dependências inativas serão ativadas (e ocorrerá a propagação de outros trabalhos conforme as relações definidas). Isso ocorre porque o trabalho enfileirado é comparado ao estado da unidade de destino no momento da execução e é marcado como bem-sucedido e concluído quando ambos os estados correspondem. No entanto, esse trabalho também envolve outras dependências devido às relações definidas e, assim, leva, em nosso exemplo, ao enfileiramento de trabalhos de inicialização para quaisquer dessas unidades inativas.
As unidades podem ser geradas dinamicamente durante a inicialização e no momento da recarga do gerenciador de sistema, por exemplo, com base em outros arquivos de configuração ou parâmetros passados na linha de comando do kernel. Para obter detalhes, consulte systemd.generator(7).
DIRETÓRIOS
Diretórios de unidades do sistema O gerenciador de sistema systemd lê a configuração da unidade de vários diretórios. Os pacotes que desejam instalar arquivos de unidade devem colocá-los no diretório retornado por pkg-config systemd --variable=systemdsystemunitdir. Outros diretórios verificados são /usr/local/lib/systemd/system e /usr/lib/systemd/system. A configuração do usuário sempre tem precedência. pkg-config systemd --variable=systemdsystemconfdir retorna o caminho do diretório de configuração do sistema.
Os pacotes devem alterar o conteúdo desses diretórios apenas com os comandos enable e disable da ferramenta systemctl(1). A lista completa de diretórios é fornecida em systemd.unit(5).
Diretórios de unidades do usuário Regras semelhantes se aplicam aos diretórios de unidades do usuário. No entanto, aqui, a especificação XDG Base Directory[5] é seguida para encontrar as unidades. Os aplicativos devem colocar seus arquivos de unidade no diretório retornado por pkg-config systemd --variable=systemduserunitdir. A configuração global é feita no diretório relatado por pkg-config systemd --variable=systemduserconfdir. Os comandos enable e disable da ferramenta systemctl(1) podem lidar com o enable/disable global (ou seja, para todos os usuários) e privado (para um único usuário) de unidades. A lista completa de diretórios é fornecida em systemd.unit(5).
SINAIS
O serviço escuta vários sinais de processo UNIX que podem ser usados para solicitar várias ações de forma assíncrona. O tratamento de sinais é habilitado muito cedo durante a inicialização, antes que quaisquer outros processos sejam invocados. No entanto, um gerenciador de contêineres supervisor ou similar que pretende solicitar essas operações por meio desse mecanismo deve levar em consideração que essa funcionalidade não está disponível durante a fase de inicialização mais inicial. Uma mensagem de notificação sd_notify() contendo o campo X_SYSTEMD_SIGNALS_LEVEL=2 é emitida quando os manipuladores de sinal são habilitados, consulte abaixo. Isso pode ser usado para agendar corretamente o envio desses sinais.
SIGTERM
Ao receber este sinal, o gerenciador de sistema systemd serializa seu estado, reinicia a si mesmo
e desserializa o estado salvo novamente. Isso é praticamente equivalente a systemctl daemon-reexec.
Os gerenciadores de usuário systemd iniciarão a unidade `exit.target` quando este sinal for recebido. Isso é
praticamente equivalente a `systemctl --user start exit.target --job-mode=replace-irreversibly`.
SIGINT
Ao receber este sinal, o gerenciador de sistema systemd iniciará a unidade ctrl-alt-del.target. Isso é
praticamente equivalente a systemctl start ctrl-alt-del.target --job-mode=replace-irreversibly. Se este sinal for recebido mais de 7 vezes em 2 segundos, uma reinicialização imediata é acionada. Observe que pressionar Ctrl+Alt+Del no console acionará
este sinal. Portanto, se uma reinicialização estiver travada, pressionar Ctrl+Alt+Del mais de 7 vezes em 2
segundos é uma maneira relativamente segura de acionar uma reinicialização imediata.
Os gerenciadores de usuário systemd tratam este sinal da mesma forma que SIGTERM.
SIGWINCH
Quando este sinal é recebido, o gerenciador de sistema systemd iniciará a unidade kbrequest.target.
Isso é praticamente equivalente a systemctl start kbrequest.target.
Este sinal é ignorado pelos gerenciadores de usuário systemd.
SIGPWR
Quando este sinal é recebido, o gerenciador systemd iniciará a unidade sigpwr.target. Isso é
praticamente equivalente a systemctl start sigpwr.target.
SIGUSR1
Quando este sinal é recebido, o gerenciador systemd tentará reconectar-se ao barramento D-Bus.
SIGUSR2
Quando este sinal é recebido, o gerenciador systemd registrará seu estado completo em
um formato legível por humanos. Os dados registrados são os mesmos impressos por systemd-analyze dump.
SIGHUP
Recarrega a configuração completa do daemon. Isso é praticamente equivalente a systemctl daemon-reload.
SIGRTMIN+0
Entra no modo padrão, inicia a unidade default.target. Isso é praticamente equivalente a systemctl isolate default.target.
SIGRTMIN+1
Entra no modo de resgate, inicia a unidade rescue.target. Isso é praticamente equivalente a systemctl isolate rescue.target.
SIGRTMIN+2
Entra no modo de emergência, inicia a unidade emergency.service. Isso é praticamente equivalente a systemctl isolate emergency.service.
SIGRTMIN+3
Desliga a máquina, inicia a unidade halt.target. Isso é praticamente equivalente a systemctl start halt.target --job-mode=replace-irreversibly.
SIGRTMIN+4
Desliga a máquina, inicia a unidade poweroff.target. Isso é praticamente equivalente a systemctl start poweroff.target --job-mode=replace-irreversibly.
SIGRTMIN+5
Reinicia a máquina, inicia a unidade reboot.target. Isso é praticamente equivalente a systemctl start reboot.target --job-mode=replace-irreversibly.
SIGRTMIN+6
Reinicia a máquina via kexec, inicia a unidade kexec.target. Isso é praticamente equivalente a systemctl start kexec.target --job-mode=replace-irreversibly.
SIGRTMIN+7
Reinicia o espaço do usuário, inicia a unidade soft-reboot.target. Isso é em grande parte equivalente a systemctl start soft-reboot.target --job-mode=replace-irreversibly.
Adicionado na versão 254.
SIGRTMIN+13
Interrompe a máquina imediatamente.
SIGRTMIN+14
Desliga a máquina imediatamente.
SIGRTMIN+15
Reinicia a máquina imediatamente.
SIGRTMIN+16
Reinicia a máquina imediatamente com kexec.
SIGRTMIN+17
Reinicia o espaço do usuário imediatamente.
Adicionado na versão 254.
SIGRTMIN+20
Habilita a exibição de mensagens de status no console, conforme controlado por systemd.show_status=1 na linha de comando do kernel.
Você pode querer usar SetShowStatus() em vez de SIGRTMIN+20 para evitar condições de corrida. Veja org.freedesktop.systemd1(5).
SIGRTMIN+21
Desabilita a exibição de mensagens de status no console, conforme controlado por systemd.show_status=0 na linha de comando do kernel.
Você pode querer usar SetShowStatus() em vez de SIGRTMIN+21 para evitar condições de corrida. Veja org.freedesktop.systemd1(5).
SIGRTMIN+22
Define o nível de registro do gerenciador de serviços para "debug", de uma forma equivalente a systemd.log_level=debug na linha de comando do kernel.
SIGRTMIN+23
Restaura o nível de registro para seu valor configurado. O valor configurado é derivado – em ordem de prioridade – do valor especificado com systemd.log-level= na linha de comando do kernel, ou do valor especificado com LogLevel= no arquivo de configuração, ou do padrão interno de "info".
Adicionado na versão 239.
SIGRTMIN+24
Sai do gerenciador imediatamente (disponível apenas para instâncias --user).
Adicionado na versão 195.
SIGRTMIN+25
Ao receber este sinal, o gerenciador systemd irá reexecutar-se. Isso é em grande parte equivalente a systemctl daemon-reexec, exceto que será feito de forma assíncrona.
O gerenciador de sistema systemd trata este sinal da mesma forma que SIGTERM.
Adicionado na versão 250.
SIGRTMIN+26
Restaura o destino de registro para seu valor configurado. O valor configurado é derivado – em ordem de prioridade – do valor especificado com systemd.log-target= na linha de comando do kernel, ou do valor especificado com LogTarget= no arquivo de configuração, ou do padrão interno.
Adicionado na versão 239.
SIGRTMIN+27, SIGRTMIN+28
Define o destino de registro para "console" em SIGRTMIN+27 (ou "kmsg" em SIGRTMIN+28), de uma forma equivalente a systemd.log_target=console (ou systemd.log_target=kmsg em SIGRTMIN+28) na linha de comando do kernel.
Adicionado na versão 239.
AMBIENTE
O bloco de ambiente para o gerenciador de sistema é inicialmente definido pelo kernel. (Em particular, as atribuições "key=value" na linha de comando do kernel são transformadas em variáveis de ambiente para PID 1. Para o gerenciador de usuário, o gerenciador de sistema define o ambiente conforme descrito na seção "Variáveis de Ambiente em Processos Gerados" de systemd.exec(5). A configuração DefaultEnvironment= no gerenciador de sistema se aplica a todos os serviços, incluindo [email protected]. Entradas adicionais podem ser configuradas (como para qualquer outro serviço) através das configurações Environment= e EnvironmentFile= para [email protected] (veja systemd.exec(5)). Além disso, variáveis de ambiente adicionais podem ser definidas através da configuração ManagerEnvironment= em systemd-system.conf(5) e systemd-user.conf(5).
Algumas das variáveis compreendidas pelo systemd:
$SYSTEMD_LOG_LEVEL
O nível máximo de log das mensagens emitidas (mensagens com um nível de log mais alto, ou seja, menos importantes, serão suprimidas). Aceita uma lista separada por vírgulas de valores. Um valor pode ser um dos seguintes (em ordem decrescente de importância): emerg, alert, crit, err, warning, notice, info, debug, ou um inteiro no intervalo de 0 a 7. Consulte syslog(3) para obter mais informações. Cada valor pode ser opcionalmente prefixado com um dos seguintes: console, syslog, kmsg ou journal, seguido de dois pontos, para definir o nível máximo de log para esse destino de log específico (por exemplo, SYSTEMD_LOG_LEVEL=debug,console:info especifica para registrar no nível de depuração, exceto ao registrar no console, que deve estar no nível de informação). Observe que o nível máximo de log global tem precedência sobre quaisquer níveis máximos de log por destino.
Pode ser substituído com --log-level=.
$SYSTEMD_LOG_COLOR
Um booleano. Se verdadeiro, as mensagens gravadas no tty serão coloridas de acordo com a prioridade.
Pode ser substituído com --log-color=.
$SYSTEMD_LOG_TIME
Um booleano. Se verdadeiro, as mensagens de log do console serão prefixadas com um carimbo de data/hora.
Adicionado na versão 246.
Pode ser substituído com --log-time=.
$SYSTEMD_LOG_LOCATION
Um booleano. Se verdadeiro, as mensagens serão prefixadas com um nome de arquivo e número de linha no código-fonte de onde a mensagem se origina.
Pode ser substituído com --log-location=.
$SYSTEMD_LOG_TID
Um booleano. Se verdadeiro, as mensagens serão prefixadas com o ID de thread numérico atual (TID).
Adicionado na versão 247.
$SYSTEMD_LOG_TARGET
O destino para as mensagens de log. Um dos seguintes: console (registrar no tty anexado), console-prefixed (registrar no tty anexado, mas com prefixos que codificam o nível de log e a "facility", consulte syslog(3)), kmsg (registrar no buffer de log circular do kernel), journal (registrar no journal), journal-or-kmsg (registrar no journal, se disponível, e em kmsg, caso contrário), auto (determinar o destino de log apropriado automaticamente, o padrão), null (desativar a saída de log).
Pode ser substituído com --log-target=.
$SYSTEMD_LOG_RATELIMIT_KMSG
Indica se deve limitar a taxa de mensagens para kmsg ou não. Aceita um booleano. O padrão é "true". Se desabilitado, o systemd não limitará a taxa de mensagens gravadas em kmsg.
Adicionado na versão 254.
$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
O gerenciador de usuários systemd usa essas variáveis em conformidade com a especificação XDG Base Directory[5] para encontrar sua configuração.
$SYSTEMD_UNIT_PATH, $SYSTEMD_GENERATOR_PATH, $SYSTEMD_ENVIRONMENT_GENERATOR_PATH
Controla onde o systemd procura arquivos de unidade e geradores.
Essas variáveis podem conter uma lista de caminhos, separados por dois pontos (":"). Quando definido, se a lista terminar com um componente vazio ("...:"), essa lista será prefixada ao conjunto usual de caminhos. Caso contrário, a lista especificada substituirá o conjunto usual de caminhos.
$SYSTEMD_PAGER, $PAGER
Paginador a ser usado quando --no-pager não for especificado. $SYSTEMD_PAGER é usado se estiver definido; caso contrário, $PAGER
é usado. Se nem $SYSTEMD_PAGER nem $PAGER estiverem definidos, uma série de paginadores conhecidos é testada em sequência, incluindo [less]({filename}../../less)(1) e more(1), até que um seja encontrado. Se nenhum
paginador for descoberto, nenhum paginador será invocado. Definir essas variáveis de ambiente
para uma string vazia ou o valor "cat" é equivalente a passar --no-pager.
Observação: se $SYSTEMD_PAGERSECURE não estiver definido, $SYSTEMD_PAGER e $PAGER só podem ser usados para
desativar o paginador (com "cat" ou ""), e, caso contrário, são ignorados.
$SYSTEMD_LESS
Substitui as opções passadas para less (por padrão "FRSXMK").
Os usuários podem querer alterar duas opções em particular:
K
Esta opção instrui o paginador a sair imediatamente quando Ctrl+C for pressionado. Para permitir que less trate Ctrl+C por conta própria para retornar ao prompt de comando do paginador, desative esta opção.
Se o valor de $SYSTEMD_LESS não incluir "K" e o paginador invocado for less, Ctrl+C será ignorado pelo executável e precisará ser tratado pelo paginador.
X
Esta opção instrui o paginador a não enviar strings de inicialização e desinicialização termcap para o terminal. Está definido por padrão para permitir que a saída do comando permaneça visível
no terminal mesmo após a saída do paginador. No entanto, isso impede que alguma funcionalidade do paginador funcione, em particular, a saída paginada não pode ser rolada com o mouse.
Observe que definir a variável de ambiente regular $LESS não tem efeito para invocações de less
por ferramentas systemd.
Consulte [less]({filename}../../less)(1) para mais informações.
$SYSTEMD_LESSCHARSET
Substitui o conjunto de caracteres passado para less (por padrão "utf-8", se o terminal que invoca for
determinado como compatível com UTF-8).
Observe que definir a variável de ambiente regular $LESSCHARSET não tem efeito para invocações de less
por ferramentas systemd.
$SYSTEMD_PAGERSECURE
Comandos comuns de paginador como [less]({filename}../../less)(1), além de "paginação", ou seja, rolagem da
saída, suportam a abertura ou gravação em outros arquivos e a execução de comandos shell arbitrários.
Quando os comandos são invocados com privilégios elevados, por exemplo, sob [sudo]({filename}../../sudo)(8) ou pkexec(1),
o paginador se torna um limite de segurança. Deve-se ter cuidado para que apenas programas com funcionalidade estritamente
limitada sejam usados como paginadores, e recursos interativos não intencionais, como abertura ou
criação de novos arquivos ou início de subprocessos, não sejam permitidos. O "modo seguro" para o
paginador pode ser habilitado, conforme descrito abaixo, se o paginador suportar isso (a maioria dos paginadores não
é escrita de forma a levar isso em consideração). Recomenda-se habilitar explicitamente o "modo seguro" ou desativar completamente o paginador usando --no-pager ou PAGER=cat quando
permitir que usuários não confiáveis executem comandos com privilégios elevados.
Esta opção recebe um argumento booleano. Quando definido como verdadeiro, o "modo seguro" do paginador é habilitado. No "modo seguro", LESSSECURE=1 será definido ao invocar o paginador, o que instrui o paginador a desabilitar comandos que abrem ou criam novos arquivos ou iniciam novos subprocessos. Atualmente, apenas less(1) é conhecido por entender essa variável e implementar o "modo seguro".
Quando definido como falso, nenhuma limitação é imposta ao paginador. Definir SYSTEMD_PAGERSECURE=0 ou não removê-lo do ambiente herdado pode permitir que o usuário invoque comandos arbitrários.
Quando $SYSTEMD_PAGERSECURE não está definido, as ferramentas systemd tentam determinar automaticamente se o "modo seguro" deve ser habilitado e se o paginador o suporta. O "modo seguro" é habilitado se o UID efetivo não for o mesmo que o do proprietário da sessão de login, veja geteuid(2) e sd_pid_get_owner_uid(3), ou quando executado sob sudo(8) ou ferramentas semelhantes ($SUDO_UID está definido [6]). Nesses casos, SYSTEMD_PAGERSECURE=1 será definido e os paginadores que não são conhecidos por implementar o "modo seguro" não serão usados. Observe que essa detecção automática cobre apenas os mecanismos mais comuns para elevar privilégios e é destinada à conveniência. Recomenda-se definir explicitamente $SYSTEMD_PAGERSECURE ou desabilitar o paginador.
Observe que se as variáveis $SYSTEMD_PAGER ou $PAGER devem ser honradas, além de desabilitar o paginador, $SYSTEMD_PAGERSECURE também deve ser definido.
$SYSTEMD_COLORS
Recebe um argumento booleano. Quando verdadeiro, systemd e utilitários relacionados usarão cores em sua saída; caso contrário, a saída será monocromática. Além disso, a variável pode assumir um dos seguintes valores especiais: "16", "256" para restringir o uso de cores às 16 ou 256 cores ANSI básicas, respectivamente. Isso pode ser especificado para substituir a decisão automática com base em $TERM e no que o console está conectado.
$SYSTEMD_URLIFY
O valor deve ser booleano. Controla se links clicáveis devem ser gerados na saída para emuladores de terminal que ofereçam suporte a isso. Isso pode ser especificado para substituir a decisão que o systemd faz com base em $TERM e outras condições.
$LISTEN_PID, $LISTEN_PIDFDID, $LISTEN_FDS, $LISTEN_FDNAMES
Definido pelo systemd para processos supervisionados durante a ativação baseada em soquete. Veja sd_listen_fds(3) para mais informações.
$NOTIFY_SOCKET
Definido pelo gerenciador de serviços para seus serviços para notificações de status e prontidão. Também consumido pelo gerenciador de serviços para notificar gerenciadores de contêineres ou gerenciadores de serviço superiores na hierarquia sobre seu próprio progresso. Veja sd_notify(3) e a seção relevante abaixo para mais informações.
Para obter mais variáveis de ambiente compreendidas pelo systemd e seus vários componentes, veja Variáveis de Ambiente Conhecidas[7].
LINHA DE COMANDO DO KERNEL
Quando executado como a instância do sistema, systemd analisa várias opções listadas abaixo. Elas podem ser especificadas como argumentos da linha de comando do kernel, que são analisados a partir de várias fontes, dependendo do ambiente no qual systemd é executado. Se executado dentro de um contêiner Linux, essas opções são analisadas a partir dos argumentos da linha de comando passados ao próprio systemd, além de quaisquer opções da linha de comando listadas na seção Opções acima. Se executado fora dos contêineres Linux, esses argumentos são analisados a partir de /proc/cmdline.
As seguintes variáveis são compreendidas:
systemd.unit=, rd.systemd.unit=
Substitui a unidade a ser ativada na inicialização. O padrão é default.target. Isso pode ser usado para inicializar temporariamente em uma unidade de inicialização diferente, por exemplo, rescue.target ou emergency.service. Consulte systemd.special(7) para obter detalhes sobre essas unidades. A opção prefixada com "rd." é honrada apenas no initrd, enquanto a que não é prefixada, apenas no sistema principal.
systemd.dump_core
Aceita um argumento booleano ou habilita a opção se especificada sem um argumento. Se habilitada, o gerenciador systemd (PID 1) faz um despejo de memória quando ocorre uma falha. Caso contrário, nenhum despejo de memória é criado. O padrão é habilitado.
Adicionado na versão 233.
systemd.crash_chvt
Aceita um inteiro positivo ou um argumento booleano. Também pode ser especificada sem um argumento, com o mesmo efeito de um booleano positivo. Se um inteiro positivo (na faixa de 1 a 63) for especificado, o gerenciador de sistema (PID 1) ativará o terminal virtual especificado quando ocorrer uma falha. O padrão é desabilitado, o que significa que nenhuma troca será tentada. Se definido como habilitado, o terminal virtual para o qual as mensagens do kernel são gravadas será usado em vez disso.
Adicionado na versão 233.
systemd.crash_shell
Aceita um argumento booleano ou habilita a opção se especificada sem um argumento. Se habilitada, o gerenciador systemd (PID 1) inicia um shell quando ocorre uma falha. Caso contrário, nenhum shell será iniciado. O padrão é desabilitado, por motivos de segurança, pois o shell não é protegido por autenticação de senha.
Adicionado na versão 233.
systemd.crash_action=
Aceita um dos valores "freeze", "reboot" ou "poweroff". O padrão é "freeze". Se definido como "freeze", o sistema travará indefinidamente quando o gerenciador systemd (PID 1) falhar. Se definido como "reboot", o gerenciador systemd (PID 1) reiniciará automaticamente a máquina quando ocorrer uma falha, após um atraso de 10 segundos. Se definido como "poweroff", o gerenciador systemd (PID 1) desligará a máquina imediatamente quando ocorrer uma falha. Se combinado com systemd.crash_shell, a ação de falha configurada será executada após a saída do shell.
Adicionado na versão 256.
systemd.confirm_spawn
Aceita um argumento booleano ou um caminho para o console virtual onde as mensagens de confirmação devem ser emitidas. Também pode ser especificada sem um argumento, com o mesmo efeito de um booleano positivo. Se habilitado, o gerenciador systemd (PID 1) solicita confirmação ao iniciar processos usando /dev/console. Se um caminho ou um nome de console (como "ttyS0") for fornecido, o console virtual apontado por este caminho ou descrito pelo nome fornecido será usado em vez disso. O padrão é desabilitado.
Adicionado na versão 233.
systemd.service_watchdogs=
Aceita um argumento booleano. Se desativado, todos os watchdogs de tempo de execução do serviço (WatchdogSec=) e ações de emergência (por exemplo, OnFailure= ou StartLimitAction=) são ignorados pelo gerenciador de sistema (PID 1); veja systemd.service(5). O padrão é habilitado, ou seja, os watchdogs e ações de falha são processados normalmente. O watchdog de hardware não é afetado por esta opção.
Adicionado na versão 237.
systemd.show_status
Aceita um argumento booleano ou as constantes error e auto. Também pode ser especificado sem um argumento, com o mesmo efeito de um booleano positivo. Se habilitado, o gerenciador systemd (PID 1) exibe atualizações de status de serviço concisas no console durante a inicialização. Com error, apenas mensagens sobre falhas são exibidas, mas a inicialização permanece silenciosa. auto se comporta como false até que haja um atraso significativo na inicialização. O padrão é habilitado, a menos que quiet seja passado como uma opção de linha de comando do kernel, caso em que o padrão é error. Se especificado, substitui a opção de arquivo de configuração do gerenciador de sistema ShowStatus=, veja systemd-system.conf(5).
Adicionado na versão 233.
systemd.status_unit_format=
Aceita name, description ou combined como valor. Se name, o gerenciador de sistema usará os nomes das unidades nas mensagens de status. Se combined, o gerenciador de sistema usará os nomes das unidades e a descrição nas mensagens de status. Quando especificado, substitui a opção de arquivo de configuração do gerenciador de sistema StatusUnitFormat=, veja systemd-system.conf(5).
Adicionado na versão 243.
systemd.log_color, systemd.log_level=, systemd.log_location, systemd.log_target=,
systemd.log_time, systemd.log_tid, systemd.log_ratelimit_kmsg
Controla a saída de registro, com o mesmo efeito das variáveis de ambiente $SYSTEMD_LOG_COLOR, $SYSTEMD_LOG_LEVEL,
$SYSTEMD_LOG_LOCATION, $SYSTEMD_LOG_TARGET, $SYSTEMD_LOG_TIME, $SYSTEMD_LOG_TID e
$SYSTEMD_LOG_RATELIMIT_KMSG descritas acima. systemd.log_color,
systemd.log_location, systemd.log_time, systemd.log_tid e systemd.log_ratelimit_kmsg podem ser
especificados sem um argumento, com o mesmo efeito de um booleano positivo.
systemd.default_standard_output=, systemd.default_standard_error=
Controla a saída padrão e o erro padrão para serviços e sockets. Ou seja, controla o padrão para StandardOutput= e StandardError= (veja systemd.exec(5) para detalhes). Aceita um dos valores inherit, null, tty, journal, journal+console, kmsg, kmsg+console. Se o argumento for omitido, systemd.default-standard-output= terá como padrão journal e systemd.default-standard-error= terá como padrão inherit.
systemd.setenv=
Aceita um argumento de string no formato VARIABLE=VALUE. Pode ser usado para definir variáveis de ambiente padrão a serem adicionadas aos processos filhos bifurcados. Pode ser usado mais de uma vez para definir várias variáveis.
systemd.machine_id=
Aceita um valor hexadecimal de 32 caracteres a ser usado para definir o machine-id. Destinado principalmente ao boot de rede, onde o mesmo machine-id é desejado para cada boot.
Adicionado na versão 229.
systemd.set_credential=, systemd.set_credential_binary=
Define uma credencial de sistema, que pode então ser propagada para serviços de sistema usando
a configuração ImportCredential= ou LoadCredential=, veja systemd.exec(5) para detalhes. Aceita um par
de nome e valor da credencial, separados por dois pontos. O parâmetro systemd.set_credential=
espera o valor da credencial em formato de texto literal, o parâmetro systemd.set_credential_binary=
aceita dados binários codificados em Base64. Observe que a linha de comando do kernel é normalmente
acessível por programas não privilegiados em /proc/cmdline. Portanto, este mecanismo não é adequado
para transferir dados confidenciais. Use-o apenas para dados que não são confidenciais (por exemplo, chaves/certificados públicos, em vez de chaves privadas) ou em ambientes de teste/depuração.
Para mais informações, consulte a documentação [System and Service Credentials].
Adicionado na versão 251.
systemd.import_credentials=
Aceita um argumento booleano. Se for falso, desativa a importação de credenciais da linha de comando do kernel,
da tabela de strings OEM DMI/SMBIOS, do subsistema qemu_fw_cfg ou do stub do kernel EFI.
Adicionado na versão 251.
quiet
Desativa a saída de status durante a inicialização, semelhante a systemd.show\_status=no. Observe que esta opção
também é lida pelo próprio kernel e desativa a saída do log do kernel. Passar esta opção desativa, portanto,
a saída usual do gerenciador de sistema e do kernel.
Adicionado na versão 186.
debug
Ativa a saída de depuração. Isso é equivalente a systemd.log\_level=debug. Observe que esta opção
também é lida pelo próprio kernel e ativa a saída de depuração do kernel. Passar esta opção ativa, portanto,
a saída de depuração do gerenciador de sistema e do kernel.
Adicionado na versão 205.
emergency, rd.emergency, -b
Inicia no modo de emergência. Isso é equivalente a systemd.unit=emergency.target ou
rd.systemd.unit=emergency.target, respectivamente, e fornecido por razões de compatibilidade e para
ser mais fácil de digitar.
Adicionado na versão 186.
rescue, rd.rescue, single, s, S, 1
Inicia no modo de resgate. Isso é equivalente a systemd.unit=rescue.target ou
rd.systemd.unit=rescue.target, respectivamente, e fornecido por razões de compatibilidade e para
ser mais fácil de digitar.
Adicionado na versão 186.
2 3, 4, 5
Inicia no nível de execução SysV legado especificado. 2, 3 e 4 são equivalentes a
systemd.unit=multi-user.target; e 5 é equivalente a systemd.unit=graphical.target, e fornecido por razões de compatibilidade e para
ser mais fácil de digitar.
Adicionado na versão 186.
locale.LANG=, locale.LANGUAGE=, locale.LC_CTYPE=, locale.LC_NUMERIC=, locale.LC_TIME=,
locale.LC_COLLATE=, locale.LC_MONETARY=, locale.LC_MESSAGES=, locale.LC_PAPER=, locale.LC_NAME=,
locale.LC_ADDRESS=, locale.LC_TELEPHONE=, locale.LC_MEASUREMENT=, locale.LC_IDENTIFICATION=
Define o locale do sistema a ser usado. Isso substitui as configurações em /etc/locale.conf. Para mais
informações, consulte locale.conf(5) e locale(7).
Adicionado na versão 186.
Para outros parâmetros da linha de comando do kernel compreendidos pelos componentes do sistema operacional principal, consulte
kernel-command-line(7).
CREDENCIAIS DO SISTEMA
Durante a inicialização, o gerenciador de serviços importará credenciais de várias fontes para o conjunto de credenciais do sistema, que então podem ser propagadas para os serviços e consumidas por geradores:
Quando o gerenciador de serviços for inicializado pela primeira vez, ele lerá as credenciais do sistema das strings do SMBIOS Tipo 11, io.systemd.credential:name=value e io.systemd.credential.binary:name=value.
Ao mesmo tempo, ele importará credenciais do QEMU "fw_cfg". (Observe que o mecanismo SMBIOS é geralmente preferido, porque é mais rápido e genérico.)
As credenciais podem ser passadas pela linha de comando do kernel, usando o parâmetro systemd.set-credential=, veja acima.
As credenciais podem ser passadas do ambiente UEFI através do systemd-stub(7).
Quando o gerenciador de serviços é invocado durante a transição initrd → host, ele importará todos os arquivos em /run/credentials/@initrd/ como credenciais do sistema.
Invoque systemd-creds(1) da seguinte forma para ver a lista de credenciais passadas para o sistema:
# systemd-creds --system list
Para mais informações, consulte a documentação System and Service Credentials[8].
O gerenciador de serviços, quando executado como PID 1, consome as seguintes credenciais do sistema:
vmm.notify_socket
Contém um endereço AF_VSOCK ou AF_UNIX para onde enviar uma mensagem de notificação READY=1 quando o gerenciador de serviços tiver concluído a inicialização. Veja sd_notify(3) e a próxima seção para mais informações. Observe que, caso o hipervisor não suporte SOCK_DGRAM sobre AF_VSOCK, SOCK_SEQPACKET será tentado em vez disso. A carga útil da credencial para AF_VSOCK deve ser uma string no formato "vsock:CID:PORT". "vsock-stream", "vsock-dgram" e "vsock-seqpacket" podem ser usados em vez de "vsock" para forçar o uso do tipo de soquete correspondente.
Este recurso é útil para gerentes de máquina ou outros processos no host para receber uma notificação via VSOCK quando uma máquina virtual tiver terminado de inicializar.
Adicionado na versão 254.
system.machine_id
Assume um ID hexadecimal de 128 bits para inicializar /etc/machine-id, se o arquivo ainda não estiver configurado. Veja machine-id(5) para detalhes.
Adicionado na versão 254.
Para uma lista de credenciais do sistema que vários outros componentes do systemd consomem, veja systemd.systemcredentials(7).
PROTOCOLO DE PRONTIDÃO
O gerenciador de serviços implementa um protocolo de notificação de prontidão, tanto entre o gerenciador e seus serviços (isto é, para baixo na pilha) e entre o gerenciador e um possível supervisor mais acima na pilha (este último pode ser um gerente de máquina ou de contêiner, ou, no caso de um gerente de serviços por usuário, a instância do gerenciador de serviços do sistema). O protocolo básico (e a API sugerida para ele) está descrito em sd_notify(3).
O soquete de notificação que o gerenciador de serviços (incluindo PID 1) usa para relatar a prontidão ao seu próprio supervisor é definido pela variável de ambiente usual $NOTIFY_SOCKET (veja acima). Como isso pode ser definido diretamente apenas para gerenciadores de contêineres e para a instância por usuário do gerenciador de serviços, um mecanismo adicional para configurar isso está disponível, em particular, destinado ao uso em ambientes de VM: a credencial do sistema vmm.notify_socket (veja acima) pode ser definida para um soquete adequado (normalmente um AF_VSOCK) via strings de fornecedor do SMBIOS Tipo 11. Para detalhes, veja acima.
O protocolo de notificação do gerenciador de serviços, que é enviado para cima na pilha em direção a um supervisor, oferece suporte a vários campos de extensão que permitem que um supervisor aprenda sobre propriedades específicas do sistema e acompanhe o progresso da inicialização. Especificamente, os seguintes campos são enviados:
Uma mensagem X_SYSTEMD_HOSTNAME=... será enviada assim que o nome do host inicial do sistema for determinado. Observe que, durante a execução posterior, o nome do host pode ser alterado novamente por meio de programação, e (atualmente) nenhuma notificação adicional é enviada nesse caso.
Adicionado na versão 256.
Uma mensagem X_SYSTEMD_MACHINE_ID=... será enviada assim que o ID da máquina do sistema for determinado. Consulte machine-id(5) para obter detalhes.
Adicionado na versão 256.
Uma mensagem X_SYSTEMD_SIGNALS_LEVEL=... será enviada assim que o gerenciador de serviços instalar os vários manipuladores de sinal de processo UNIX descritos acima. O valor do campo é um inteiro não assinado formatado como uma string decimal e indica o nível de recurso de sinal de processo UNIX suportado pelo gerenciador de serviços. Atualmente, apenas um nível de recurso é definido:
X_SYSTEMD_SIGNALS_LEVEL=2 cobre os vários sinais de processo UNIX documentados acima –
que são um superconjunto daqueles suportados pelo sistema SysV init histórico.
Os sinais enviados para o PID 1 antes que esta mensagem seja enviada podem não ser tratados corretamente. Um consumidor dessas mensagens deve analisar o valor como um inteiro não assinado que indica o nível de suporte. Por enquanto, apenas o nível mencionado 2 é definido, mas, no futuro, níveis adicionais podem ser definidos com inteiros mais altos, que implementarão um superconjunto do comportamento atualmente definido.
Adicionado na versão 256.
As mensagens X_SYSTEMD_UNIT_ACTIVE=... e X_SYSTEMD_UNIT_INACTIVE=... serão enviadas para cada unidade de destino à medida que ela se torna ativa ou deixa de ser ativa. Isso é útil para acompanhar o progresso da inicialização e a funcionalidade. Por exemplo, assim que a unidade ssh-access.target for relatada como iniciada, o acesso SSH estará normalmente disponível, consulte systemd.special(7) para obter detalhes.
Adicionado na versão 256.
Uma mensagem X_SYSTEMD_SHUTDOWN=... será enviada logo antes do desligamento do sistema. O valor é um dos strings "reboot", "halt", "poweroff" e "kexec" e indica qual tipo de desligamento está sendo executado.
Adicionado na versão 256.
Uma mensagem X_SYSTEMD_REBOOT_PARAMETER=... também será enviada logo antes do desligamento do sistema. O valor é o argumento de reinicialização, conforme configurado com systemctl --reboot-argument=....
Adicionado na versão 256.
Observe que esses campos de extensão são enviados além das notificações regulares "READY=1" e "RELOADING=1".
OPÇÕES
systemd é invocado diretamente apenas raramente, pois é iniciado no início e já está em execução
quando os usuários podem interagir com ele. Normalmente, ferramentas como [systemctl]({filename}../../systemctl)(1) são usadas para enviar comandos
para o gerenciador. Como systemd geralmente não é invocado diretamente, as opções listadas abaixo
são principalmente úteis para depuração e fins especiais.
Opções de introspecção e depuração
Essas opções são usadas para testes e introspecção, e o systemd pode ser invocado com elas a qualquer momento:
--dump-configuration-items
Exibe os itens de configuração de unidade compreendidos. Isso gera uma lista concisa, mas completa, dos itens de configuração compreendidos nos arquivos de definição de unidade.
--dump-bus-properties
Exibe as propriedades do barramento expostas. Isso gera uma lista concisa, mas completa, das propriedades expostas no D-Bus.
Adicionado na versão 239.
--test
Determina a transação inicial de inicialização (ou seja, a lista de tarefas enfileiradas na inicialização), exibe-a e sai — sem realmente executar nenhuma das tarefas determinadas. Esta opção é útil apenas para depuração. Observe que, durante a inicialização normal do gerenciador de serviços, unidades adicionais não mostradas por esta operação podem ser iniciadas, porque hardware, socket, barramento ou outros tipos de ativação podem adicionar tarefas adicionais à medida que a transação é executada. Use --system para solicitar a transação inicial do gerenciador de serviços do sistema (este é também o padrão implícito), combine com --user para solicitar a transação inicial da instância por usuário em vez disso.
--system, --user
Quando usado em conjunto com --test, seleciona se deve calcular a transação inicial para a instância do sistema ou para uma instância por usuário. Essas opções não têm efeito quando invocadas sem --test, pois durante invocações regulares (ou seja, não --test), o gerenciador de serviços detectará automaticamente se deve operar no modo do sistema ou por usuário, verificando se o PID em que está sendo executado é 1 ou não. Observe que não é suportado inicializar e manter um sistema com o gerenciador de serviços em execução no modo --system, mas com um PID diferente de 1.
-h, --help
Imprime um texto de ajuda curto e sai.
--version
Imprime uma string de versão curta e sai.
Opções que duplicam as configurações da linha de comando do kernel
Essas opções correspondem diretamente às opções listadas acima em "Linha de comando do kernel". Ambas as formas podem ser usadas de forma equivalente para o gerenciador de sistema, mas é recomendável usar as formas listadas acima neste contexto, porque elas são devidamente nomeadas. Quando uma opção é especificada tanto na linha de comando do kernel quanto como um argumento de linha de comando normal, a última tem precedência.
Quando o systemd é usado como um gerenciador de usuário, a linha de comando do kernel é ignorada e apenas as opções descritas abaixo são compreendidas. No entanto, o systemd geralmente é iniciado neste modo por meio do serviço [email protected](5), que é compartilhado entre todos os usuários. Pode ser mais conveniente usar arquivos de configuração para modificar as configurações (consulte systemd-user.conf(5)) ou variáveis de ambiente. Veja a seção "Ambiente" acima para uma discussão sobre como o bloco de ambiente é definido.
--unit=
Define a unidade padrão a ser ativada na inicialização. Se não for especificado, o padrão será default.target. Consulte systemd.unit= acima.
--dump-core
Habilita o despejo de memória em caso de falha. Essa opção não tem efeito quando executado como uma instância de usuário. Equivalente a systemd.dump_core= acima.
--crash-vt=VT
Altera para um console virtual (VT) específico em caso de falha. Essa opção não tem efeito quando executado como uma instância de usuário. Equivalente a systemd.crash_chvt= acima (mas com grafia diferente!).
Adicionado na versão 227.
--crash-shell
Executa um shell em caso de falha. Essa opção não tem efeito quando executado como uma instância de usuário. Consulte systemd.crash_shell= acima.
--crash-action=
Especifica o que fazer quando o gerenciador de sistema (PID 1) falha. Essa opção não tem efeito quando o systemd está sendo executado como uma instância de usuário. Consulte systemd.crash_action= acima.
Adicionado na versão 256.
--confirm-spawn
Solicita confirmação ao iniciar processos. Essa opção não tem efeito quando executado como uma instância de usuário. Consulte systemd.confirm_spawn acima.
--show-status
Exibe informações resumidas do status da unidade no console durante a inicialização e o desligamento. Consulte systemd.show_status acima.
Adicionado na versão 244.
--log-color
Realça mensagens importantes do log. Consulte systemd.log_color acima.
Adicionado na versão 244.
--log-level=
Define o nível de log. Consulte systemd.log_level acima.
--log-location
Inclui o código-fonte nos logs. Consulte systemd.log_location acima.
Adicionado na versão 244.
--log-target=
Define o destino do log. Consulte systemd.log_target acima.
--log-time=
Adiciona um carimbo de data/hora às mensagens do console. Consulte systemd.log_time acima.
Adicionado na versão 246.
--machine-id=
Substitui o machine-id definido no disco rígido. Consulte systemd.machine_id= acima.
Adicionado na versão 229.
--service-watchdogs
Habilita ou desabilita globalmente todos os timeouts e ações de emergência do watchdog de serviço. Consulte systemd.service_watchdogs acima.
Adicionado na versão 237.
--default-standard-output=, --default-standard-error=
Define a saída padrão ou a saída de erro padrão para todos os serviços e sockets, respectivamente. Consulte systemd.default_standard_output= e systemd.default_standard_error= acima.
ÉPOCA DO RELÓGIO DO SISTEMA
Quando o systemd é iniciado ou reiniciado, ele pode definir o relógio do sistema para a "época". Este mecanismo é usado para garantir que o relógio do sistema permaneça razoavelmente inicializado e aproximadamente monotônico entre as reinicializações, caso nenhuma RTC local com bateria esteja disponível ou não funcione corretamente.
A época é a data mais antiga acima da qual o tempo do relógio do sistema é considerado corretamente definido. Ao inicializar, o relógio local é avançado para a época se foi definido para um valor anterior. Como caso especial, se o relógio local estiver muito à frente (por padrão, 15 anos, mas isso pode ser configurado no momento da compilação), o relógio de hardware é considerado defeituoso e o relógio do sistema é retrocedido para a época.
A época é definida como o maior valor entre: o tempo de compilação do systemd, o tempo de modificação ("mtime") de /usr/lib/clock-epoch e o tempo de modificação de /var/lib/systemd/timesync/clock.
ARQUIVOS
/run/systemd/notify
Socket de notificação de status do daemon. Este é um socket datagrama AF\_UNIX e é usado para implementar a lógica de notificação do daemon conforme implementado por sd_notify(3).
/run/systemd/private
Usado internamente como canal de comunicação entre [systemctl]({filename}../../systemctl)(1) e o processo systemd. Este é um socket stream AF_UNIX. Esta interface é privada do systemd e não deve ser usada em projetos externos.
/usr/lib/clock-epoch
O tempo de modificação ("mtime") deste arquivo é usado para a época do tempo, veja a seção anterior.
Adicionado na versão 247.
/var/lib/systemd/timesync/clock
O tempo de modificação ("mtime") deste arquivo é atualizado por systemd-timesyncd.service(8). Se presente, o tempo de modificação do arquivo é usado para a época, veja a seção anterior.
Adicionado na versão 257.
HISTÓRICO
systemd 252
Os argumentos da linha de comando do kernel systemd.unified_cgroup_hierarchy e systemd.legacy_systemd_cgroup_controller foram descontinuados. Por favor, altere para a hierarquia unificada de cgroup.
VEJA TAMBÉM
A página inicial do systemd[9], systemd-system.conf(5), locale.conf(5), [systemctl]({filename}../../systemctl)(1), [journalctl]({filename}../../journalctl)(1), systemd-notify(1), daemon(7), sd-daemon(3), org.freedesktop.systemd1(5), systemd.unit(5), systemd.special(7), pkg-config(1), kernel-command-line(7), bootup(7), systemd.directives(7), org.freedesktop.systemd1(5)
Para obter mais informações sobre os conceitos e ideias por trás do systemd, consulte o Documento de Design Original[10].
NOTAS
Interface Portabilidade e Estabilidade
https://systemd.io/PORTABILITY_AND_STABILITY/
Interface de Contêiner
https://systemd.io/CONTAINER_INTERFACE
Interface initrd
https://systemd.io/INITRD_INTERFACE/
Control Groups v2
https://docs.kernel.org/admin-guide/cgroup-v2.html
Especificação do Diretório Base XDG
https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
Recomenda-se que outras ferramentas definam e verifiquem $SUDO_UID conforme apropriado, tratando-o como uma interface comum.
Variáveis de Ambiente Conhecidas
https://systemd.io/ENVIRONMENT
Credenciais de Sistema e Serviço
https://systemd.io/CREDENTIALS
Página inicial do systemd
https://systemd.io/
Documento de Design Original
https://0pointer.de/blog/projects/systemd.html