InglêsFrancêsEspanhol

Ad


favicon do OnWorks

systemd - Online na nuvem

Execute o systemd no provedor de hospedagem gratuita OnWorks no Ubuntu Online, Fedora Online, emulador online do Windows ou emulador online do MAC OS

Este é o comando systemd que pode ser executado no provedor de hospedagem gratuita OnWorks usando uma de nossas várias estações de trabalho online gratuitas, como Ubuntu Online, Fedora Online, emulador online do Windows ou emulador online do MAC OS

PROGRAMA:

NOME


systemd, init - sistema systemd e gerenciador de serviços

SINOPSE


sistema [OPÇÕES ...]

o init [OPÇÕES ...] {COMANDO}

DESCRIÇÃO


systemd é um gerenciador de sistema e serviço para sistemas operacionais Linux. Quando executado como primeiro
processo na inicialização (como PID 1), ele atua como sistema de inicialização que abre e mantém o espaço do usuário
serviços.

Para compatibilidade com SysV, se systemd for chamado de o init e um PID que não é 1, ele vai
executar telini e passar todos os argumentos da linha de comando sem modificações. Que significa o init e
telini são geralmente equivalentes quando chamados de sessões de login normais. Ver telini(8) para
Mais Informações.

Quando executado como uma instância do sistema, o systemd interpreta o arquivo de configuração system.conf e
os arquivos nos diretórios system.conf.d; quando executado como uma instância do usuário, o systemd interpreta
o arquivo de configuração user.conf e os arquivos nos diretórios user.conf.d. Ver sistema-
sistema.conf(5) para mais informações.

OPÇÕES


As seguintes opções são compreendidas:

--teste
Determine a sequência de inicialização, descarte-a e saia. Esta é uma opção útil para depuração
só.

--dump-itens de configuração
Despeje os itens de configuração da unidade compreendidos. Isso resulta em uma lista concisa, mas completa de
itens de configuração compreendidos em arquivos de definição de unidade.

--unit =
Defina a unidade padrão para ativar na inicialização. Se não for especificado, o padrão é default.target.

--sistema, --do utilizador
Escolha --sistema, diga ao systemd para executar uma instância do sistema, mesmo se o ID do processo não for 1,
ou seja, o systemd não é executado como um processo init. --do utilizador faz o oposto, executando um usuário
instância, mesmo se o ID do processo for 1. Normalmente, não deve ser necessário passar
essas opções, pois o systemd detecta automaticamente o modo em que é iniciado.
as opções são, portanto, de pouca utilidade, exceto para depuração. Observe que não é compatível
inicializando e mantendo um sistema completo com o systemd rodando em --sistema modo, mas PID
não 1. Na prática, passando --sistema explicitamente só é útil em conjunto com
--teste.

--dump-núcleo
Habilite o despejo de núcleo no travamento. Esta opção não tem efeito quando executado como instância do usuário.
Esta configuração também pode ser habilitada durante a inicialização na linha de comando do kernel através do
systemd.dump_core = opção, veja abaixo.

--crash-vt =VT
Mude para um console virtual (VT) específico em caso de falha. Pega um número inteiro positivo no
intervalo de 1 a 63 ou um argumento booleano. Se um número inteiro for passado, seleciona qual VT alternar
para. Se sim, as mensagens do kernel VT são gravadas é selecionado. Se não, nenhuma chave VT é
tentada. Esta opção não tem efeito quando executado como instância do usuário. Esta configuração pode
também pode ser habilitado durante a inicialização, na linha de comando do kernel por meio do systemd.crash_vt =
opção, veja abaixo.

--crash-shell
Execute um shell ao travar. Esta opção não tem efeito quando executado como instância do usuário. Esse
configuração também pode ser habilitada durante a inicialização, na linha de comando do kernel através do
systemd.crash_shell = opção, veja abaixo.

--reinicialização de falha
Reinicialize automaticamente o sistema ao travar. Esta opção não tem efeito quando executado como
instância do usuário. Esta configuração também pode ser habilitada durante a inicialização, no comando do kernel
linha através do systemd.crash_reboot = opção, veja abaixo.

--confirm-spawn
Peça confirmação quando estiver gerando processos. Esta opção não tem efeito quando executado como
instância do usuário.

--show-status =
Mostra informações concisas de status do serviço durante a inicialização. Esta mudança não tem efeito quando
executado como instância do usuário. Aceita um argumento booleano que pode ser omitido que é
interpretado como verdadeiro.

--log-target =
Defina o destino do log. O argumento deve ser um dos consolá, revista, kmsg, diário-ou-kmsg, nulo.

--log-level =
Defina o nível de registro. Como argumento, isso aceita um nível de log numérico ou o conhecido
syslog(3) nomes simbólicos (minúsculas): emergir, alerta, crit, errar, aviso, aviso prévio, info,
depurar.

--log-color =
Destaque mensagens de log importantes. O argumento é um valor booleano. Se o argumento for
omitido, o padrão é verdadeiro.

--log-location =
Inclua a localização do código nas mensagens de log. Isso é mais relevante para fins de depuração.
O argumento é um valor booleano. Se o argumento for omitido, o padrão é verdadeiro.

--default-standard-output =, --default-standard-error =
Define a saída padrão ou saída de erro para todos os serviços e soquetes, respectivamente.
Ou seja, controla o padrão para StandardOutput = e StandardError = (Vejo
systemd.exec(5) para detalhes). Pega um de herdar, nulo, tty, revista,
diário + console, syslog, syslog + console, kmsg, kmsg + console. Se o argumento for
omitidos --default-standard-output = o padrão é revista e --default-standard-error =
para herdar.

--machine-id =
Substitua o conjunto de id da máquina no disco rígido, útil para inicialização de rede ou para
containers. Não pode ser definido para todos os zeros.

-h, --Socorro
Imprima um breve texto de ajuda e saia.

--versão
Imprima uma string de versão curta e saia.

CONCEITOS


O systemd fornece um sistema de dependência entre várias entidades chamadas "unidades" de 12
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 são configuradas em arquivos de configuração de unidades, cujo
a sintaxe e o conjunto básico de opções são descritos em unidade do sistema(5), porém alguns são criados
automaticamente a partir de outra configuração, dinamicamente a partir do estado do sistema ou programaticamente
em tempo de execução. As unidades podem estar "ativas" (significando iniciado, vinculado, conectado, ..., dependendo
o tipo de unidade, veja abaixo), ou "inativo" (significando parada, não ligada, desconectada, ...), como
bem como em processo de ativação ou desativação, ou seja, entre os dois estados
(esses estados são chamados de "ativando", "desativando"). Um estado especial de "falha" é
disponível também, que é muito semelhante a "inativo" e é inserido quando o serviço
falhou de alguma forma (o processo retornou um código de erro na saída, travou ou uma operação cronometrada
Fora). Se este estado for inserido, a causa será registrada para referência posterior. Observe que
os vários tipos de unidade podem ter uma série de subestados adicionais, que são mapeados para o
cinco estados de unidade generalizados descritos aqui.

Os seguintes tipos de unidade estão disponíveis:

1. Unidades de serviço, que iniciam e controlam daemons e os processos em que consistem. Para
detalhes, veja systemd.serviço(5).

2. Unidades de soquete, que encapsulam o IPC local ou soquetes de rede no sistema, úteis para
ativação baseada em soquete. Para obter detalhes sobre unidades de soquete, consulte soquete do sistema(5), para
detalhes sobre ativação baseada em soquete e outras formas de ativação, consulte demônio(7).

3. As unidades de destino são úteis para agrupar unidades ou fornecer pontos de sincronização bem conhecidos
durante a inicialização, veja systemd.target(5).

4. As unidades de dispositivo expõem os dispositivos do kernel no systemd e podem ser usadas para implementar
ativação baseada no dispositivo. Para detalhes, veja systemd.dispositivo(5).

5. As unidades de montagem controlam os pontos de montagem no sistema de arquivos, para obter detalhes, consulte systemd.mount(5).

6. Unidades automount fornecem recursos automount, para montagem sob demanda de sistemas de arquivos
bem como inicialização paralelizada. Ver systemd.automount(5).

7. Unidades de cronômetro são úteis para acionar a ativação de outras unidades com base em cronômetros. Vocês
pode encontrar detalhes em systemd.timer(5).

8. As unidades de troca são muito semelhantes às unidades de montagem e encapsulam partições de troca de memória ou
arquivos do sistema operacional. Eles são descritos em troca do sistema(5).

9. As unidades de caminho podem ser usadas para ativar outros serviços quando os objetos do sistema de arquivos mudam ou
são modificados. Ver systemd.caminho(5).

10. As unidades de fatia podem ser usadas para agrupar unidades que gerenciam os processos do sistema (como serviço
e unidades de escopo) em uma árvore hierárquica para fins de gerenciamento de recursos. Ver
systemd.slice(5).

11. As unidades de escopo são semelhantes às unidades de serviço, mas gerenciam processos estrangeiros em vez de
iniciá-los também. Ver 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.especial(7).

O systemd conhece vários tipos de dependências, incluindo requisitos positivos e negativos
dependências (ou seja Requer = e Conflitos =), bem como dependências de ordenação (Depois = e
Antes =) NB: as dependências de pedidos e requisitos são ortogonais. Se apenas um requisito
dependência existe entre duas unidades (por exemplo, foo.service requer bar.service), mas não
dependência de ordenação (por exemplo, foo.service após bar.service) e ambos são solicitados para iniciar,
eles serão iniciados em paralelo. É um padrão comum que tanto o requisito quanto
as dependências de pedidos são colocadas entre duas unidades. Observe também que a maioria dos
dependências são criadas e mantidas implicitamente pelo systemd. Na maioria dos casos, deve ser
desnecessário declarar dependências adicionais manualmente, no entanto, é possível fazer
esta.

Unidades e programas aplicativos (por meio de dependências) podem solicitar mudanças de estado das unidades. No
systemd, esses pedidos são encapsulados como 'trabalhos' e mantidos em uma fila de trabalhos. Trabalhos podem
ter sucesso ou falhar, sua execução é ordenada com base nas dependências de ordenação do
unidades para as quais foram programados.

Na inicialização, o systemd ativa a unidade alvo default.target, cujo trabalho é ativar na inicialização
serviços e outras unidades na inicialização, puxando-os por meio de dependências. Normalmente, a unidade
nome é apenas um apelido (link simbólico) para gráfico.target (para inicializações completas em
a IU) ou multi-user.target (para inicializações limitadas apenas de console para uso em servidor integrado ou
ambientes ou semelhantes; um subconjunto de graphical.target). No entanto, fica a critério
do administrador para configurá-lo como um alias para qualquer outra unidade de destino. Ver
systemd.especial(7) para obter detalhes sobre essas unidades alvo.

Os spawns do systemd de processos são colocados em grupos de controle individuais do Linux nomeados após o
unidade a que pertencem na hierarquia do sistema privado. (Vejo cgroups.txt[1] para mais
informações sobre grupos de controle ou curtos "cgroups"). systemd usa isso para efetivamente
acompanhar os processos. As informações do grupo de controle são mantidas no kernel e são
acessível através da hierarquia do sistema de arquivos (abaixo / sys / fs / cgroup / systemd /), ou em ferramentas
tais como systemd-cgls(1) ou ps(1) (ps xawf -eo pid, usuário, cgroup, args é particularmente útil
para listar todos os processos e as unidades do systemd a que pertencem.).

systemd é compatível com o sistema de inicialização SysV em um alto grau: os scripts de inicialização SysV são
suportado e simplesmente lido como um formato de arquivo de configuração alternativo (embora limitado).
A interface SysV / dev / initctl é fornecida e as implementações de compatibilidade do
várias ferramentas de cliente SysV estão disponíveis. Além disso, vários Unix estabelecidos
funcionalidade como / etc / fstab ou o banco de dados utmp são suportados.

systemd tem um sistema de transação mínimo: se uma unidade é solicitada para iniciar ou desligar
ele irá adicioná-lo e todas as suas dependências a uma transação temporária. Então, ele vai verificar
se a transação for consistente (ou seja, se o pedido de todas as unidades é livre de ciclos).
Se não estiver, o systemd tentará consertá-lo e removerá os trabalhos não essenciais do
transação que pode remover o loop. Além disso, o systemd tenta suprimir trabalhos não essenciais
na transação que interromperia um serviço em execução. Finalmente, é verificado se o
jobs da transação contradizem jobs que já foram enfileirados e, opcionalmente, o
a transação é abortada então. Se tudo deu certo e a transação é consistente e
minimizado em seu impacto, é mesclado com todos os trabalhos já pendentes e adicionado ao
fila de execução. Efetivamente, isso significa que antes de executar uma operação solicitada, o systemd
irá verificar se faz sentido, corrigindo-o se possível, e somente falhando se realmente
Não pode trabalhar.

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 a rede de loopback
dispositivo. Ele também configura e monta vários sistemas de arquivos API, como / sys ou / proc.

Para obter mais informações sobre os conceitos e ideias por trás do systemd, consulte o
Óptimo estado. Original Design ISO[2].

Observe que algumas, mas não todas as interfaces fornecidas pelo systemd são cobertas pelo Interface
Estabilidade Promessa[3].

As unidades podem ser geradas dinamicamente na inicialização e tempo de recarga do gerenciador do sistema, por exemplo
com base em outros arquivos de configuração ou parâmetros passados ​​na linha de comando do kernel. Para
detalhes, veja systemd.gerador(7).

Os sistemas que invocam o systemd em um ambiente container ou initrd devem implementar o
Recipiente Interface[4] ou initrd Interface[5] especificações, respectivamente.

DIRETÓRIOS


Diretórios de unidades do sistema
O gerenciador do sistema systemd lê a configuração da unidade de vários diretórios. Pacotes
que deseja instalar arquivos de unidade deve colocá-los no diretório retornado por
pacote-config sistema --variable = systemdsystemunitdir. Outros diretórios verificados são
/ usr / local / lib / systemd / system e / lib / systemd / system. A configuração do usuário sempre leva
precedência. pacote-config sistema --variable = systemdsystemconfdir retorna o caminho de
o diretório de configuração do sistema. Os pacotes devem alterar o conteúdo destes
diretórios apenas com o permitir e desabiltar comandos do systemctl(1) ferramenta. Cheio
lista de diretórios é fornecida em unidade do sistema(5).

Diretórios de unidades do usuário
Regras semelhantes se aplicam aos diretórios de unidades do usuário. No entanto, aqui o XDG Fundo
Diretório especificação[6] é seguido para encontrar unidades. Os aplicativos devem colocar seus
arquivos de unidade no diretório retornado por pacote-config sistema
--variable = systemduserunitdir. A configuração global é feita no diretório relatado
by pacote-config sistema --variable = systemduserconfdir. O permitir e desabiltar comandos
da systemctl(1) ferramenta pode lidar tanto global (ou seja, para todos os usuários) e privado (para
um usuário) habilitar / desabilitar unidades. A lista completa de diretórios é fornecida em
unidade do sistema(5).

Diretório de scripts de inicialização SysV
A localização do diretório de script de inicialização SysV varia entre as distribuições. Se
O systemd não consegue encontrar um arquivo de unidade nativa para um serviço solicitado, ele irá procurar por um
Script de inicialização SysV com o mesmo nome (com o sufixo .service removido).

Diretório do farm de links de nível de execução SysV
A localização do diretório farm do link de nível de execução SysV varia entre as distribuições.
O systemd levará o link farm em consideração ao descobrir se um serviço deve
ser habilitado. Observe que uma unidade de serviço com um arquivo de configuração de unidade nativa não pode ser
começou ativando-o no farm de links de nível de execução SysV.

SINAIS


PRAZO META
Ao receber este sinal, o gerenciador do sistema systemd serializa seu estado, executa novamente
a si mesmo e desserializa o estado salvo novamente. Isso é basicamente equivalente a systemctl
daemon-reexec.

os gerenciadores de usuários do systemd iniciarão a unidade exit.target quando este sinal for recebido.
Isso é basicamente equivalente a systemctl --do utilizador começo saída.alvo.

SIGINT
Ao receber este sinal, o gerenciador do sistema systemd iniciará o
ctrl-alt-del.target unit. Isso é basicamente equivalente a systemctl começo
ctl-alt-del.target. Se este sinal for recebido mais de 7 vezes por 2s, um imediato
a reinicialização é acionada. Observe que pressionar Ctrl-Alt-Del no console irá acionar este
sinal. Portanto, se uma reinicialização estiver travada, pressione Ctrl-Alt-Del mais de 7 vezes em 2s
é uma maneira relativamente segura de acionar uma reinicialização imediata.

os gerentes de usuários do systemd tratam este sinal da mesma forma que PRAZO META.

SIGWINCH
Quando este sinal for recebido, o gerenciador do sistema systemd irá iniciar o
unidade kbrequest.target. Isso é basicamente equivalente a systemctl começo kbrequest.target.

Este sinal é ignorado pelos gerenciadores de usuários do systemd.

SIGPWR
Quando este sinal for recebido, o gerenciador do systemd iniciará a unidade sigpwr.target.
Isso é basicamente equivalente a systemctl começo sigpwr.target.

SIGUSR1
Quando este sinal for recebido, o gerenciador do systemd tentará se reconectar ao D-Bus
ônibus.

SIGUSR2
Quando este sinal for recebido, o gerenciador do systemd registrará seu estado completo em
forma legível por humanos. Os dados registrados são os mesmos impressos por systemd-analyse despejar.

SIGA
Recarrega a configuração completa do daemon. Isso é basicamente equivalente a systemctl
recarregar daemon.

SIGRTMIN + 0
Entra no modo padrão, inicia a unidade default.target. Isso é basicamente equivalente a
systemctl começo padrão.alvo.

SIGRTMIN + 1
Entra no modo de resgate e inicia a unidade rescue.target. Isso é basicamente equivalente a
systemctl isolar resgate.alvo.

SIGRTMIN + 2
Entra no modo de emergência e inicia a unidade de serviço de emergência. Isso é basicamente equivalente a
systemctl isolar serviço de emergência.

SIGRTMIN + 3
Para a máquina, inicia a unidade halt.target. Isso é basicamente equivalente a systemctl
começo parar.alvo.

SIGRTMIN + 4
Desliga a máquina e inicia a unidade poweroff.target. Isso é basicamente equivalente a
systemctl começo desligar.target.

SIGRTMIN + 5
Reinicializa a máquina, inicia a unidade reboot.target. Isso é basicamente equivalente a
systemctl começo reiniciar.alvo.

SIGRTMIN + 6
Reinicializa a máquina via kexec, inicia a unidade kexec.target. Isso é basicamente equivalente
para systemctl começo kexec.target.

SIGRTMIN + 13
Para imediatamente a máquina.

SIGRTMIN + 14
Desliga a máquina imediatamente.

SIGRTMIN + 15
Reinicializa a máquina imediatamente.

SIGRTMIN + 16
Reinicializa imediatamente a máquina com kexec.

SIGRTMIN + 20
Habilita a exibição de mensagens de status no console, conforme controlado via
systemd.show_status = 1 na linha de comando do kernel.

SIGRTMIN + 21
Desativa a exibição de mensagens de status no console, conforme controlado por
systemd.show_status = 0 na linha de comando do kernel.

SIGRTMIN + 22, SIGRTMIN + 23
Define o nível de registro para "depurar" (ou "informações" em SIGRTMIN + 23), conforme controlado por meio de
systemd.log_level = debug (ou systemd.log_level = info on SIGRTMIN + 23) no kernel
linha de comando.

SIGRTMIN + 24
Sai imediatamente do gerenciador (disponível apenas para instâncias --user).

SIGRTMIN + 26, SIGRTMIN + 27, SIGRTMIN + 28
Define o nível de registro para "journal-or-kmsg" (ou "console" em SIGRTMIN + 27, "kmsg" em
SIGRTMIN + 28), conforme controlado por meio de systemd.log_target = journal-or-kmsg (ou
systemd.log_target = console on SIGRTMIN + 27 or systemd.log_target = kmsg on SIGRTMIN + 28)
na linha de comando do kernel.

MEIO AMBIENTE


$ SYSTEMD_LOG_LEVEL
systemd lê o nível de log desta variável de ambiente. Isso pode ser substituído
de --log-level =.

$ SYSTEMD_LOG_TARGET
systemd lê o destino do log a partir desta variável de ambiente. Isso pode ser substituído
de --log-target =.

$ SYSTEMD_LOG_COLOR
Controla se o systemd destaca mensagens de log importantes. Isso pode ser substituído
de --log-color =.

$ SYSTEMD_LOG_LOCATION
Controla se o systemd imprime o local do código junto com as mensagens de log. Isso pode ser
substituído com --log-location =.

$ XDG_CONFIG_HOME, $ XDG_CONFIG_DIRS, $ XDG_DATA_HOME, $ XDG_DATA_DIRS
O gerenciador de usuários do systemd usa essas variáveis ​​de acordo com o XDG Fundo Diretório
especificação[6] para encontrar sua configuração.

$ SYSTEMD_UNIT_PATH
Controla onde o systemd procura por arquivos de unidade.

$ SYSTEMD_SYSVINIT_PATH
Controla onde o systemd procura por scripts de inicialização SysV.

$ SYSTEMD_SYSVRCND_PATH
Controla onde o systemd procura por farms de links de nível de execução de script de inicialização SysV.

$ SYSTEMD_COLORS
Controla se a saída colorida deve ser gerada.

$ LISTEN_PID, $ LISTEN_FDS, $ LISTEN_FDNAMES
Definido pelo systemd para processos supervisionados durante a ativação baseada em soquete. Ver
sd_listen_fds(3) para mais informações.

$ NOTIFY_SOCKET
Definido pelo systemd para processos supervisionados para status e conclusão de inicialização
notificação. Ver sd_notify(3) para mais informações.

NÚCLEO COMANDO LINHA


Quando executado como instância do sistema, o systemd analisa vários argumentos da linha de comando do kernel [7]:

systemd.unit =, rd.systemd.unit =
Substitui a unidade para ativar 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
serviço de emergência. Ver systemd.especial(7) para obter detalhes sobre essas unidades. A opção
prefixado com "rd." é honrado apenas no disco RAM inicial (initrd), enquanto o
que não é prefixado apenas no sistema principal.

systemd.dump_core =
Aceita um argumento booleano. Se sim, o gerenciador do systemd (PID 1) despeja o núcleo quando ele
trava. Caso contrário, nenhum dump de memória será criado. Padrões para sim.

systemd.crash_chvt =
Aceita um número inteiro positivo ou um argumento booleano. Se for um número inteiro positivo (no intervalo
1–63) for especificado, o gerenciador do sistema (PID 1) ativará o virtual especificado
terminal (VT) quando ele trava. Padrões para não, o que significa que nenhuma mudança é
tentada. Se definido para sim, o VT em que as mensagens do kernel são gravadas é selecionado.

systemd.crash_shell =
Aceita um argumento booleano. Se sim, o gerenciador do sistema (PID 1) gera um shell quando
travar, após um atraso de 10s. Caso contrário, nenhum shell é gerado. Padrões para não, Por
razões de segurança, já que o shell não é protegido por autenticação de senha.

systemd.crash_reboot =
Aceita um argumento booleano. Se sim, o gerenciador do sistema (PID 1) irá reiniciar a máquina
automaticamente quando ele trava, após um atraso de 10s. Caso contrário, o sistema irá travar
indefinidamente. Padrões para não, para evitar um loop de reinicialização. Se combinado com
systemd.crash_shell =, o sistema será reinicializado após a saída do shell.

systemd.confirm_spawn =
Aceita um argumento booleano. Se sim, o gerenciador do sistema (PID 1) pede confirmação
quando processos de desova. Padrões para não.

systemd.show_status =
Utiliza um argumento booleano ou a constante auto. Se sim, o gerenciador systemd (PID 1)
mostra atualizações concisas de status de serviço no console durante a inicialização. auto se comporta como
falso até que um serviço falhe ou haja um atraso significativo na inicialização. Padrões para sim,
a menos que calma é passado como opção de linha de comando do kernel, caso em que o padrão é
auto.

systemd.log_target =, systemd.log_level =, systemd.log_color =, systemd.log_location =
Controla a saída do registro, com o mesmo efeito que o $ SYSTEMD_LOG_TARGET,
$ SYSTEMD_LOG_LEVEL, $ SYSTEMD_LOG_COLOR, $ SYSTEMD_LOG_LOCATION variáveis ​​ambientais
descrito acima.

systemd.default_standard_output =, systemd.default_standard_error =
Controla a saída padrão padrão e a saída de erro para serviços, com o mesmo efeito
como o --default-standard-output = e --default-standard-error = argumentos de linha de comando
descrito acima, respectivamente.

systemd.setenv =
Aceita um argumento de string no formato VARIABLE = VALUE. Pode ser usado para definir o padrão
variáveis ​​de ambiente a serem adicionadas aos processos filho bifurcados. Pode ser usado mais de uma vez para
definir várias variáveis.

systemd.machine_id =
Requer um valor hexadecimal de 32 caracteres para ser usado para definir a id da máquina. Destinado principalmente
para inicialização de rede onde a mesma id de máquina é desejada para cada inicialização.

calma
Desligue a saída de status na inicialização, bem como systemd.show_status = false seria. Observe que
esta opção também é lida pelo próprio kernel e desabilita a saída de log do kernel. Passagem
esta opção, portanto, desativa a saída usual do gerenciador de sistema e do
núcleo.

depurar
Ative 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. Passagem
esta opção, portanto, ativa a saída de depuração do gerenciador de sistema e do
núcleo.

kit, -b
Inicialize no modo de emergência. Isso é equivalente a systemd.unit = Emergency.target e
fornecido por razões de compatibilidade e para ser mais fácil de digitar.

resgatar, solteiro, s, S, 1
Inicialize no modo de recuperação. Isso é equivalente a systemd.unit = rescue.target e fornecido
por razões de compatibilidade e para ser mais fácil de digitar.

2, 3, 4, 5
Inicialize no nível de execução SysV legado especificado. Estes são equivalentes a
systemd.unit = runlevel2.target, systemd.unit = runlevel3.target,
systemd.unit = runlevel4.target e systemd.unit = runlevel5.target, respectivamente, e
fornecido por razões de compatibilidade e para ser mais fácil de digitar.

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 =
Defina a localidade do sistema a ser usada. Isso substitui as configurações em /etc/locale.conf. Para
mais informações, veja locale.conf(5) e local(7).

Para outros parâmetros de linha de comando do kernel compreendidos por componentes do sistema operacional central, por favor
referem-se a linha de comando do kernel(7).

TOMADAS E FIFOS


/ run / systemd / notificar
Soquete de notificação de status do daemon. Isto é um AF_UNIX socket de datagrama e é usado para
implementar a lógica de notificação daemon conforme implementada por sd_notify(3).

/ run / systemd / private
Usado internamente como canal de comunicação entre systemctl(1) e o processo systemd.
Esta é uma AF_UNIX tomada de fluxo. Esta interface é privada para o systemd e não deve
ser usado em projetos externos.

/ dev / initctl
Suporte de compatibilidade limitado para a interface do cliente SysV, conforme implementado pelo
unidade systemd-initctl.service. Este é um canal nomeado no sistema de arquivos. Esta interface
está obsoleto e não deve ser usado em novos aplicativos.

Use systemd online usando serviços onworks.net


Servidores e estações de trabalho gratuitos

Baixar aplicativos Windows e Linux

Comandos Linux

Ad