sexta-feira, 3 de março de 2017

Dica de como instalar o kali no debian

Nesta post vou mostrar como fazer pra instalar o kali no debian pelo terminal.
Após ter instalado o debian somente no modo gráfico, para instalar o kali você precisa alterar o arquivo de repositório para quando atualizar o sistema já instalar o kali, mais como fazer ?
 Primeiro digite esse comando no terminal lembrando que tem que estar como root
 nano /etc/apt/source.list esse comando faz com que abra o arquivo de configuração do debian e é só mudar para esses endereços de repositórios:

deb http://http.kali.org/kali kali-rolling main contrib non-free
deb-src http://http.kali.org/kali kali-rolling main contrib non-free

deb http://old.kali.org/kali sana main non-free contrib
deb-src http://old.kali.org/kali sana main non-free contrib

deb http://old.kali.org/kali moto main non-free contrib
deb-src http://old.kali.org/kali moto main non-free contrib

Depois de o seguinte comando:
 apt update 
 apt upgrade -y
Esses dois comando irá atualizar o sistema e instalar o kali, após feito isso instale o ambiente de trabalho que desejar com o comando apt install gnome, por exemplo.
Essa foi a dica de hoje, se você consegui se ligar no repositório do debian se estiver afim de instalar outra distribuição que seja derivada do debian a dica já foi dada é só mudar o repositório, espero que essa dica tenha sido útil até a próxima.

quarta-feira, 22 de fevereiro de 2017

Entendendo o grub

Para simplificar o grub simplesmente é o responsável por carregar o boot do sistema.

E é o primeiro programa ou software que é executado quando o computador é ligado, e também é responsável por carregar e transferir controle para um sistema operacional.
E o arquivo de configuração do grub fica em  /etc/defalt/grub.
Agora vou listar os parâmetros deste arquivo e as discrição de cada um.
Para editar este arquivo use um editor de texto que você esteja acostumado.
Por exemplo nano /etc/default/grub.
Lembrando que tudo que vier depois do carácter # é comentário, e no caso dos parâmetros retire o carácter # para habilitar os parâmetros.

GRUB_DEFAULT =  É  a entrada pedrão do grub, e isso é feito por número, e por padrão é '0';


GRUB_SALVEDEFAULT =  Nesta opção se usa verdadeiro (true) ou falso (false), se selecionado verdadeiro o grub irá guardar uma entrada para futuras execuções.Esta opção se baseia no bloco de ambiente que pode não estar disponíveis em todas as situações.


GRUB_TIMEOUT = É a quantidade de segundos para a inicialização por padrão é '5' para inicio imediato defina como '0'.


GRUB_HIDDEN_TIMEOUT = Este parâmetro faz com que o sistema espere por alguns segundos para que uma tecla seja pressionada antes de exibir o menu. Caso nenhuma tecla seja pressionada durante o tempo designado o menu será exibido após o tempo designado por padrão é '0'


GRUB_HIDDEN_TIME_QUIET =  Esse parâmetros e com verdadeiro (true) ou falso (false) se for verdadeiro vai inibir a contagem que foi selecionada no parâmetro acima, por padrão é 'falso'.


GRUB_DEFAULT_BUTTON, GRUB_TIMEOUT_BUTTON, GRUB_HIDDEN_TIMEOUT_BUTTON, GRUB_BUTTON_CMOS_ADDRESS =   Variantes das variáveis ultizados para apoiar botões de energia específicos do fornecedor.


GRUB_DISTRIBUTOR = Esse parâmetro é usado para gerar entradas mais informativas no menu.

GRUB_TERMINAL_INPUT =  Seleciona om dispositivo de entrada do terminal, como consoles ( pc, bios e efi), serial ( serial terminal) ofconsole ( console de firmeware open) at keyboard (pc at teclados) usb keyboard (teclado usb). por padrão usar o nativo da plataforma ou sistema operacional.

GRUB_TERMINAL_OUTPUT =  Seleciona o dispositivo de saida,  console (consoles PC BIOS e EFI), serial (serial terminal), gfxterm (Saída de gráficos-mode), ofconsole (Console de firmware Open), ou vga_text (Saída de texto VGA), por padrão usar o nativo da plataforma ou sistema operacional.

GRUB_TERMINAL =  Se esta opção for definida substitue os  GRUB_TERMINAL_INPUT
e GRUB_TERMINAL_OUTPUT  para o mesmo valor.

GRUB_SERIAL_COMMAND = Serve para configurar uma porta serial, o padão é 'serial'.,

GRUB_CMDLINE_LINUX =  Serve para adicionar entradas de argumento do menu para o kernel.

GRUB_CMDLINE_DEFAULT = Para configurar esse parâmetro é com verdadeiro (true) ou falso (false), esta opção lista argumentos de linha de comando para adicionar uma entrada padrão depois de listados em GRUB_CMDLINE_LINUX.

GRUB_DISABLE_LINUX_UUID =  Para configura esse parâmetro é com verdadeiro (true) ou falso (false), usa indicadores exclusivos (UUIDS) para identificar o sistema de arquivos raiz para o kernel do linux, para desativar o uso de (UUDS) defina o parâmetro como verdadeiro (true) .

GRUB_DISABLE_RECOVERY = Para configurar esse parâmetro é com verdadeiro (true) ou falso (false), se esse parâmetros estiver definido como verdade (true), desativa o menu de modo de recuperação.

GRUB_VIDEO_BACKEND =  Esse parâmetro da suporte de video gráfico, carregando os drivers de video disponiveis pra seu hardware.

GRUB_GFXMODE =  Define a resolução da tela, podendo usar a placa de video que suporte as extensões bios, vesa, vbe, por padrão é 'auto'.

GRUB_BACKGROUND =  Define uma imagem de fundo, o valor deste parâmetro deve ser um arquivo com extensão .png, .tga, .jpg ou .jpeg.

GRUB_THEME =  Define um tema para uso.

GRUB_GFXPAYLOAD_LINUX =  Parâmetro 'texto' força o kernel iniciar em modo texto, parâmetro 'guarda' para modo gráfico.

GRUB_DISABLE_OS_PROBER =  Para configurar esse parâmetro é com verdadeiro (true) ou falso (false), com o parâmetro 'os-prober' se tiver instalado descobre outros sistemas operacionais instalado, gerando entradas apropriadas para eles, defina esse parâmetro como verdade (true), para desativar.

GRUB_INIT_TUNE = Toca musica no auto-falante quando o grub é iniciado.

GRUB_BADRAM =  Se esse parâmetro for definido o grub filtra as regiões da memória especificada.

GRUB_PRELOAD_MODULES = Esse parâmetro define uma lista de nomes de módulos do grub separado por espaço.

Para mais informação sobre o grub link do site manual grug.

terça-feira, 21 de fevereiro de 2017

Entendendo o systemd



Bom na postagem anterior estudamos sobre  como os diretórios são estruturado no linux, e  qual é a função de cada diretório e quais são os tipos de arquivos que pertence a cada diretório, agora vamos entender a estrutura de processos ou serviços do debian, com o comando pstree -g vai mostrar a estrutura de serviços do debian com o numero de (PID).


comando pstree


E como você pode observar o primeiro processo ou serviço é o systemd com um pid (1) , o que significa esse pid ? O pid é o identificador de processo, é uma forma que o sistema tem pra controlar e identificar os serviços que estão sendo executado, então pra entender bem o que é o pid ( é um numero de identificação dos processos ou serviços usado pelo sistema ) e como você percebeu o systemd tem o pid (1) que é o primeiro precesso ou serviço do sistema, isso quer dizer que é ele que controla todo S.O linux .



 O que é unidades do systemd ?




 systemd –dump-configuration-items →  Este comando mostra as  entidades de unidades de serviços que são: 





[Unit] 


Description= → Uma seqüência de forma livre descrevendo a unidade. Isto é pretendido para utilização em interfaces de usuário para mostrar a informação descritiva, juntamente com o nome do bloco. A descrição deve conter um nome que significa algo para o usuário final. " Apache2 Web Server " é um bom exemplo. Maus exemplos são " high-performance light-weight HTTP server " (demasiado genérico) ou " Apache2 " (muito específico e sem sentido para as pessoas que não sabem o Apache).

Documentation= → Uma lista separada por espaços de URIs documentação que fazem referência para esta unidade ou a sua configuração. Aceito são apenas URIs dos tipos de " http:// ", " https:// ", " file: ", " info: ", " man: ". Para mais informações sobre a sintaxe desses URIs . Os URIs devem ser listados em ordem de relevância, começando com o mais relevante. É uma boa idéia para a primeira documentação de referência que explica que objetivo da unidade é, seguido de como ele está configurado, seguido por qualquer outra documentação relacionada. Esta opção pode ser especificada mais de uma vez, caso em que a lista especificada de URIs é mesclado. Se a cadeia vazia é atribuído a essa opção, a lista é redefinida e todas as atribuições anteriores não terá nenhum efeito. 

Requires= → Configura dependências exigência de outras unidades. Se esta unidade é ativado, as unidades listadas aqui será ativado também. Se uma das outras unidades fica desativado ou sua ativação falhar, esta unidade será desativada. Esta opção pode ser especificada mais de uma vez ou várias unidades separadas por espaço pode ser especificado em uma opção em que as dependências requisito caso para todos os nomes listados serão criados. Observe que as dependências de exigência não influenciar a ordem em que os serviços são iniciados ou parados. Isto tem de ser configurado de forma independente com os After ou Before opções. Se uma unidade foo.service requer uma unidade bar.service como configurado com Requires e qualquer ordenamento é configurado com After ou Before , então ambas as unidades serão iniciadas simultaneamente e sem qualquer atraso entre eles se foo.service é ativado. Muitas vezes, é uma melhor escolha para usar Wants , em vez de Requires , a fim de conseguir um sistema que seja mais robusto ao lidar com serviços de falha. Note-se que as dependências deste tipo pode também ser configurado fora do arquivo de configuração da unidade, adicionando um link simbólico para um .requires/ diretório que acompanha o arquivo unidade. 
Requisite= → Semelhante a Requires . No entanto, se as unidades listadas aqui não estão já começou, eles não vão ser iniciado e a operação irá falhar imediatamente. 

Wants= → Uma versão mais fraca de Requires . Unidades listados nesta opção será iniciado se a unidade configurando é. No entanto, se as unidades indicadas não iniciar ou não pode ser adicionada à transacção, isto não tem qualquer efeito sobre a validade da operação como um todo. Esta é a maneira recomendada para ligar start-up de uma unidade para a start-up de outra unidade. Note-se que as dependências deste tipo pode também ser configurado fora do arquivo de configuração da unidade, adicionando links simbólicos para um .wants/ diretório que acompanha o arquivo unidade.

BindsTo= → Configura as dependências de exigência, muito semelhante em estilo ao Requires , no entanto, além de este comportamento, ele também declara que esta unidade é interrompido quando qualquer uma das unidades listadas repente desaparece. As unidades podem, de repente, inesperadamente desaparecer se um serviço termina a sua própria escolha, um dispositivo está desligado ou um ponto de montagem desmontado sem o envolvimento de systemd. 

PartOf= → Configura dependências semelhante ao Requires , mas limitado a parar e reiniciar de unidades. Quando systemd pára ou reinicia as unidades listadas aqui, a ação é propagado para esta unidade. Note que esta é uma dependência unidirecional  alterações a esta unidade não afetam as unidades indicadas. 

Conflicts= → Uma lista separada por espaços dos nomes das unidades. Configura as dependências de exigência negativos. Se uma unidade tem uma Conflicts configuração de uma outra unidade, começando o primeiro vai parar o segundo e vice-versa. Note que esta definição é independente e ortogonal à After e Before encomendar dependências. Se uma unidade de um que esteja em conflito com uma unidade B está programado para ser iniciado ao mesmo tempo que B, a transacção, ou falham (no caso de ambos são necessários parte da transação), ou ser modificado para ser fixo (no caso de um ou ambos postos de trabalho não são requeridas como parte da transação). Neste último caso, o trabalho que não é o exigido será removido, ou no caso de ambos não são requeridos, a unidade que os conflitos será iniciado e a unidade que está em conflito é parado. 

Before= , After= → Uma lista separada por espaços dos nomes das unidades. Configura encomendar dependências entre as unidades. Se uma unidade foo.service contém uma configuração Before=bar.service e ambas as unidades estão sendo iniciados, bar.service de start-up é adiada até foo.service é iniciado. Note que esta definição é independente e ortogonal às dependências de requisitos conforme configurado pelo Requires . É um padrão comum para incluir um nome de bloco, tanto no After e Requires opção, no caso em que a unidade listados irá ser iniciado antes de a unidade que é configurado com estas opções. Esta opção pode ser especificada mais de uma vez, no caso de encomendar dependências para todos os nomes listados que são criadas. After é o inverso Before , ou seja, enquanto After garante que a unidade configurada é iniciada após a unidade listada acabado de arranque, Before assegura o oposto, isto é, que a unidade é configurado processo de iniciação antes da unidade listada é iniciado. Observe que, quando duas unidades com uma dependência ordenação entre eles são desligados, o inverso da ordem de arranque é aplicada. ou seja, se uma unidade está configurada com After em outra unidade, o primeiro é parado antes de este último se ambos estiverem desligados. Dadas duas unidades com qualquer dependência ordenação entre eles, se uma unidade é desligado eo outro é iniciado, o desligamento é ordenada antes do start-up. Não importa se a dependência ordenação é After ou Before . Também não importa qual dos dois é desligado, enquanto um é desligado eo outro é iniciado. O desligamento é ordenada antes do start-up em todos os casos. Se duas unidades não têm dependências de ordenação entre eles, eles são desligados ou iniciado simultaneamente, e nenhuma ordenação tem lugar. 

OnFailure= → Uma lista separada por espaço de uma ou mais unidades que são ativados quando esta unidade entra no " failed estatal". 

PropagatesReloadTo= , ReloadPropagatedFrom= → Uma lista separada por espaço de uma ou mais unidades em que os pedidos de recarga nesta unidade serão propagadas para, ou recarregar pedidos na outra unidade será propagado para esta unidade, respectivamente. Emitir um pedido de recarga em uma unidade irá automaticamente também enfileirar uma solicitação de recarga em todas as unidades que o pedido de recarga deve ser propagada para via essas duas configurações. 

JoinsNamespaceOf= → Para as unidades que iniciam processos (tais como unidades de serviço), lista uma ou várias outras unidades cuja rede e / ou namespace arquivo temporário para participar. Isso só se aplica aos tipos de unidades que apoiam a PrivateNetwork e PrivateTmp directivas. Se uma unidade que tem este conjunto de configuração é iniciado, seus processos verá o mesmo /tmp , /var/tmp e namespace rede como uma unidade listada que é iniciado. Se várias unidades listadas já está iniciado, ele não está definido que namespace está associado. Note que esta definição só tem efeito se PrivateNetwork e / ou PrivateTmp está habilitado para tanto da unidade que une o namespace ea unidade cujo namespace está associado. 

RequiresMountsFor= → Recebe uma lista separada por espaços de caminhos absolutos. Adiciona automaticamente as dependências do tipo Requires e After para todas as unidades de montagem necessárias para acessar o caminho especificado. Pontos de montagem marcados com noauto não são montados automaticamente e será ignorado para o propósito desta opção. Se tal uma montagem deve ser um requisito para esta unidade, dependências diretas nas unidades de montagem pode ser adicionado (Requires e After ou alguma outra combinação). 

OnFailureJobMode= → Toma um valor de " fail ", " replace ", " replace-irreversibly ", " isolate ", " flush ", " ignore-dependencies " ou " ignore-requirements ". Padrões para " replace ". Especifica como as unidades que constam do OnFailure será enfileirado.  Se isso for definido para " isolate ", apenas uma única unidade pode ser listado em OnFailure. 
IgnoreOnIsolate= → Toma um argumento booleano. Se true , esta unidade não será interrompido ao isolar outra unidade. O padrão é false . 

StopWhenUnneeded= → Toma um argumento booleano. Se true , esta unidade será interrompida quando ele não é mais usado. Note-se que, a fim de minimizar o trabalho a ser executado, systemd não vai parar de unidades por padrão a menos que eles estão em conflito com outras unidades, ou o usuário solicitou explicitamente o seu desligamento. Se esta opção for definida, a unidade será limpa automaticamente se nenhuma outra unidade ativa exige. O padrão é false . 

RefuseManualStart= , RefuseManualStop= → Toma um argumento booleano. Se true , esta unidade só pode ser activada ou desactivada indiretamente. Neste caso, explícita start-up ou rescisão solicitada pelo usuário for negado, no entanto, se ele for iniciado ou parado como uma dependência de uma outra unidade, start-up ou rescisão será bem sucedida. Isto é mais uma característica de segurança para assegurar que o utilizador não activar acidentalmente unidades que não se destinam a ser activado de forma explícita, e não acidentalmente desactivar unidades que não se destinam a ser desactivada. Estas opções padrão para false . 

AllowIsolate= → Toma um argumento booleano. Se true , esta unidade pode ser usado com o comando systemctl isolado. Caso contrário, este será recusado. Provavelmente é uma boa idéia para deixar esta desativado, exceto para as unidades de destino que serão usados ​​semelhante ao runlevels em sistemas SysV Init, apenas como medida de precaução para evitar estados sistema inutilizável. Por padrão é false . 

DefaultDependencies= → Toma um argumento booleano. Se true , (o padrão), algumas dependências padrão irá ser implicitamente criado para a unidade. As dependências reais criados dependem do tipo de unidade. Por exemplo, para unidades de serviço, essas dependências garantir que o serviço só é iniciado após a inicialização do sistema básico está concluído e está devidamente encerrado no desligamento do sistema. Consulte as respectivas páginas de manual para detalhes. Geralmente, apenas os serviços envolvidos com a inicialização cedo ou tarde desligamento deve definir esta opção como false . É altamente recomendado que deixe esta opção habilitada para a maioria das unidades comuns. Se definido como false , esta opção não desabilita todas as dependências implícitas, apenas os não-essenciais. 

JobTimeoutSec= , JobTimeoutAction= , JobTimeoutRebootArgument= → Quando um trabalho para esta unidade está na fila, um tempo limite pode ser configurado. Se esse tempo limite é atingido, o trabalho será cancelado, a unidade, contudo, não mudará de estado ou até mesmo entrar no " failed mode". Este valor padrão é " infinity ", exceto para unidades de dispositivo.  Este tempo de espera é independente de qualquer limite de tempo específico da unidade (por exemplo, o tempo de espera definido com TimeoutStartSec em unidades de serviço) como o tempo limite do trabalho não tem efeito na própria unidade, apenas no trabalho que pode estar pendente para ele. Ou, em outras palavras: o tempo limite específico da unidade são úteis para abortar as mudanças de estado da unidade, e revertê-los. O tempo limite de trabalho definido com esta opção, porém, é útil para abortar apenas o trabalho em espera para o estado da unidade para mudar JobTimeoutAction configura opcionalmente uma ação adicional a tomar quando o tempo limite é atingido. Leva os mesmos valores como a per-service StartLimitAction definição. O padrão é none . JobTimeoutRebootArgument configura uma cadeia de reinicialização do sistema. 

StartLimitIntervalSec= , StartLimitBurst= → Configurar unidade começar a limitação de taxa. Por padrão, as unidades que são iniciados mais de 5 vezes em 10 segundos não estão autorizados a iniciar quaisquer mais vezes até as 10 segundas extremidades do intervalo. Com estas duas opções, esta limitação de velocidade pode ser modificado. Use StartLimitIntervalSec para configurar o intervalo de verificação  (padrão DefaultStartLimitIntervalSec no arquivo de configuração do gerenciador, definido como 0 para desativar qualquer tipo de limitação de taxa). Use StartLimitBurst= para configurar quantas começa por intervalo são permitidos (o padrão é DefaultStartLimitBurst= no arquivo de configuração do gerenciador). Essas opções de configuração são particularmente úteis em conjunto com a definição do serviço Restart no entanto, se aplicam a todos os tipos de partidas (incluindo manual), não apenas aqueles desencadeada pela Restart lógica. Note-se que as unidades que estão configurados para Restart e que atingir o limite de início não são tentou ser reiniciado mais; no entanto, eles ainda podem ser reiniciado manualmente em um momento posterior, a partir do qual ponto em diante, a lógica de reinício é novamente activado. Note-se que systemctl restauro de falha fará com que o contador de taxa de reinício de um serviço para ser liberado, o que é útil se o administrador deseja iniciar manualmente uma unidade e o limite de início interfere com isso. Note-se que é aplicada depois de todas as verificações de condição unidade são executadas, e, portanto, ativações de unidades com condições de falha não são contados por esta limitação de taxa este limitante da velocidade. Slice, target, de dispositivos e de escopo unidades não impor essa definição, pois eles são os tipos de unidade, cuja ativação pode falhar, ou pode ter sucesso apenas uma única vez. 

StartLimitAction= → Configurar a ação a ser tomada se o limite de velocidade configurado com StartLimitIntervalSec e StartLimitBurst é atingido. Toma um dos none , reboot , reboot-force , reboot-immediate , poweroff , poweroff-force ou poweroff-immediate . Se none estiver definido, atingindo o limite da taxa irá desencadear nenhuma ação além de que o início não será permitida. reboot causa a reinicialização após o procedimento de desligamento normal (ou seja, o equivalente a systemctl reboot). reboot-force faz com que uma reinicialização forçada que terminará tudo processos com força, mas não deve causar sistemas de arquivos sujos na reinicialização (ou seja, o equivalente a systemctl reinicialização -f) e reboot-immediate causas execução imediata do sistema, o que pode resultar em perda de dados. Da mesma forma, poweroff , poweroff-force , poweroff-immediate têm o efeito de desligar o sistema com a semântica semelhantes. O padrão é none . 

RebootArgument= → Configurar o argumento opcional para o sistema se StartLimitAction ou de um serviço de FailureAction é uma ação de reinicialização. Isto funciona como o argumento opcional para systemctl comando reboot.  
ConditionArchitecture= → pode ser usado para verificar se o sistema está sendo executado em uma arquitetura específica. Toma um dos x86 , x86-64 , ppc , ppc-le , ppc64 , ppc64-le , ia64 , parisc , parisc64 , s390 , s390x , sparc , sparc64 , mips , mips-le , mips64 , mips64-le , alpha , arm , arm-be , arm64 , arm64-be , sh , sh64 , m86k , tilegx , cris para testar contra uma arquitetura específica. A arquitetura é determinado a partir das informações retornado . Note-se que a Personality configuração no mesmo arquivo unidade não tem efeito sobre esta condição. Uma arquitetura nome especial native é mapeado para a arquitetura do gerente do sistema em si é compilado. O teste pode ser negada, antecedendo um ponto de exclamação. 

ConditionVirtualization= → pode ser utilizado para verificar se o sistema é executado em um ambiente virtual e opcionalmente testar se é uma implementação específica. Leva tanto valor booleano para verificar se está sendo executado em qualquer ambiente virtualizado, ou um dos vm e container para testar contra um tipo genérico de solução de virtualização, ou um dos qemu , kvm , zvm , vmware , microsoft , oracle , xen , bochs , uml , openvz , lxc , lxc-libvirt , systemd-nspawn , docker , rkt para testar contra uma implementação específica. Se várias tecnologias de virtualização são aninhados, somente o mais íntimo é considerada. O teste pode ser negada, antecedendo um ponto de exclamação. 

ConditionHost= →  podem ser utilizados para o jogo contra o nome de host ou máquina de ID do host. Este toma uma cadeia de hostname (opcionalmente com globs estilo shell) que é testado contra o nome do host definido localmente como retornado ou uma ID de máquina formatada como string . O teste pode ser negada, antecedendo um ponto de exclamação. 
ConditionKernelCommandLine= →  pode ser usado para verificar se uma opção de linha de comando do kernel específico está definido (ou se prefixado com o ponto de exclamação desactivado). O argumento deve ser uma única palavra ou uma atribuição (ou seja, duas palavras, separadas " = "). No primeiro caso, a linha de comando do kernel é procurado a palavra que aparece como é, ou como esquerda lado de uma atribuição. Neste último caso, a atribuição exata é procurado com harmonização lado direito e esquerdo. 

ConditionSecurity= → podem ser utilizados para verificar se um determinado módulo de segurança está habilitado no sistema. Atualmente, os valores reconhecidos são selinux , apparmor , ima , smack e audit . O teste pode ser negada, antecedendo um ponto de exclamação. 

ConditionCapability= → pode ser usado para verificar se a capacidade dada existe no conjunto de capacidades delimitadora do gerente de serviço (ou seja, este não verifica se a capacidade está realmente disponível nos conjuntos permitidos ou eficazes, passar um nome de recurso como " CAP_MKNOD ", possivelmente prefixado com um ponto de exclamação para anular a seleção. 

ConditionACPower= → pode ser utilizado para verificar se o sistema tem energia AC, ou é exclusivamente alimentado por bateria no momento da activação da unidade. Isso leva um argumento booleano. Se definido como true , a condição irá realizar somente se pelo menos um conector de CA do sistema está conectado a uma fonte de energia, ou se são conhecidos há conectores AC. Por outro lado, se for definido como false , a condição irá realizar apenas se houver pelo menos um conector AC conhecido e todos os conectores AC estiver desconectado da fonte de alimentação. 

ConditionNeedsUpdate= →  usa os diretórios /var ou /etc como argumento, possivelmente prefixado com um " ! " (Para inverter a condição). Esta condição pode ser usado para conditionalize unidades sobre se o diretório especificado requer uma atualização porque /usr  tempo de modificação é mais recente do que o arquivo  no diretório especificado. Isso é útil para implementar atualizações  dos recursos do sistema operacional do fornecedor em /usr que exigir a actualização do /etc ou /var na próxima inicialização seguinte, para se certificar que correr antes que o tempo de modificação do arquivo do selo fica redefinição indicando uma atualização concluída. 

ConditionFirstBoot= → leva um argumento booleano. Esta condição pode ser usado para  unidades se o sistema está inicializando com o diretório /etc . Isso pode ser usado para preencher /etc na primeira inicialização após o reset de fábrica, ou quando uma nova instâncias do sistema inicia-se pela primeira vez. 

ConditionPathExists= →  uma condição arquivo de existência é verificada antes de uma unidade é iniciado. Se o nome de caminho absoluto especificado não existir, a condição irá falhar. Se o nome de caminho absoluto passado para ConditionPathExists é prefixado com um ponto de exclamação ( " ! "), O teste é negada, e a unidade só é iniciado se o caminho não existe. 

ConditionPathExistsGlob= → é semelhante ao ConditionPathExists , mas verifica a existência de pelo menos um arquivo ou pasta correspondente ao padrão englobamento especificado. 

ConditionPathIsDirectory= → é semelhante ao ConditionPathExists mas verifica se um determinado caminho existe e é um diretório. 

ConditionPathIsSymbolicLink= → é semelhante ao ConditionPathExists mas verifica se um determinado caminho existe e é um link simbólico. 

ConditionPathIsMountPoint= → é semelhante ao ConditionPathExists mas verifica se um determinado caminho existe e é um ponto de montagem. 

ConditionPathIsReadWrite= → é semelhante ao ConditionPathExists mas verifica se o sistema de arquivos subjacente é legível e gravável (ou seja, não montados somente leitura). 

ConditionDirectoryNotEmpty= → é semelhante ao ConditionPathExists mas verifica se um determinado caminho existe e é um diretório não vazio. 

ConditionFileNotEmpty= → é semelhante ao ConditionPathExists mas verifica se um determinado caminho existe e se refere a um arquivo regular com um tamanho diferente de zero. 

ConditionFileIsExecutable= → é semelhante ao ConditionPathExists mas verifica se existe um caminho certo, é um arquivo executável regular e acentuada. Se são especificados várias condições, a unidade irá ser executado se todas elas se aplicam (ou seja, um lógico e é aplicado). cheques condição pode ser prefixado com um símbolo pipe (|), caso em que uma condição se torna uma condição de disparo.Se, pelo menos, uma condição de disparo é definida para uma unidade, em seguida, a unidade irá ser executado se pelo menos uma das condições que desencadeiam aplicar e todas as condições não-desencadeantes. Se você prefixar uma discussão com o símbolo pipe e um ponto de exclamação, o símbolo pipe deve ser passado em primeiro lugar, o segundo de exclamação. Exceto para ConditionPathIsSymbolicLink=, todas as verificações de caminho seguir os links. Se qualquer uma dessas opções é atribuído a cadeia vazia, a lista de condições é redefinir completamente, todas as configurações condição anterior (de qualquer tipo) não terá nenhum efeito.

AssertArchitecture=, AssertVirtualization=, AssertHost=, AssertKernelCommandLine=, AssertSecurity=, AssertCapability=, AssertACPower=, AssertNeedsUpdate=, AssertFirstBoot=, AssertPathExists=, AssertPathExistsGlob=, AssertPathIsDirectory=, AssertPathIsSymbolicLink=, AssertPathIsMountPoint=, AssertPathIsReadWrite=, AssertDirectoryNotEmpty=, AssertFileNotEmpty=, AssertFileIsExecutable= → Similar aos ConditionArchitecture, ConditionVirtualization, ..., definições de condições descritas acima, estas definições adicionar verificações de asserção para o start-up da unidade. No entanto, ao contrário das definições de condições, qualquer configuração afirmação de que não é cumprida resulta em falha do trabalho de partida (o que significa que este é registrado em voz alta). Use expressões de declaração para as unidades que não podem operar quando os requisitos específicos não são cumpridas, e quando isso é algo que o administrador ou usuário deve olhar.

SourcePath= → Um caminho para um arquivo de configuração esta unidade foi gerada a partir. Isto é principalmente útil para implementação de instrumentos geradores que convertem configuração a partir de um formato de arquivo de configuração externo em arquivos de unidades nativas. Esta funcionalidade não deve ser utilizado em unidades normais.




[Service]



PIDFile= → Leva um nome de arquivo absoluto apontando para o arquivo PID deste daemon. O uso desta opção é recomendada para serviços onde Type está definido para forking . systemd vai ler o PID do processo principal do daemon após o arranque do serviço. systemd 

RemainAfterExit=  →Aceita um valor booleano que especifica se o serviço será considerado ativo mesmo quando todos os seus processos saiu. O padrão é no . 

GuessMainPID=  → Aceita um valor booleano que especifica se systemd deve tentar adivinhar a principal PID de um serviço se ele não pode ser determinado. Esta opção é ignorada a menos Type=forking está definido e PIDFile= no está definido, porque para os outros tipos ou com um arquivo PID explicitamente configurado, o principal PID é sempre conhecido. O algoritmo de adivinhação pode chegar a conclusões incorretas se um daemon é composto por mais de um processo. Se a principal PID não pode ser determinado, detecção de falha e rearranque automático de um serviço não funcionará de forma confiável. O padrão é yes . 

BusName=  → Leva um nome de barramento D-Bus que este serviço está acessível como. Esta opção é obrigatória para os serviços onde Type está definido para dbus . 

ExecStart=  → Comandos com os seus argumentos que são executados quando este serviço é iniciado. O valor é dividido em zero ou mais linhas de comando de acordo com as regras descritas abaixo .Quando Type não é oneshot , pode e deve ser dada apenas um comando. Quando Type=oneshot é usado, zero ou mais comandos pode ser especificado. Isto pode ser especificado pelo fornecimento de várias linhas de comando na mesma directiva, ou, em alternativa, esta directiva pode ser especificado mais de uma vez com o mesmo efeito. Se a cadeia vazia é atribuído a essa opção, a lista de comandos para iniciar é reposto, as atribuições anteriores de esta opção não terá nenhum efeito. Se nenhum ExecStart  for especificado, o serviço deve ter RemainAfterExit=yes set. 
Para cada um dos comandos especificados, o primeiro argumento deve ser um caminho absoluto para um arquivo executável. Opcionalmente, se este nome de arquivo é prefixado com " @ ", o segundo marcador será passado como " argv[0] " para o processo executado, seguido pelos outros argumentos especificados. Se o nome de arquivo absoluto é prefixado com " - ", um código de saída do comando normalmente considerado um fracasso (status isto é diferente de zero saída ou saída anormal devido a um sinal) é ignorado e considerado sucesso. Se o caminho absoluto é prefixado com " + ", então ele é executado com privilégios totais. " - ", " @ ", E " + " pode ser usado em conjunto e podem aparecer em qualquer ordem. Se mais de um comando for especificado, os comandos são invocados sequencialmente na ordem em que aparecem no arquivo unidade. Se um dos comandos falhar (e não é prefixado com " - "), outras linhas não são executadas, e a unidade é considerada falhou.A menos Type=forking é definido, o processo iniciado através desta linha de comando será considerado o principal processo do daemon.

ExecStartPre= , ExecStartPost= → Os comandos adicionais que são executados antes ou depois do comando em ExecStart , respectivamente. Sintaxe é o mesmo que para ExecStart , excepto que as várias linhas de comando estão autorizados e os comandos são executados um a seguir ao outro, em série.Se algum desses comandos (não prefixados com " - ") falhar, o resto não são executados e a unidade é considerada falhou. 
ExecStart comandos apenas são executados depois de todos ExecStartPre comandos que não foram prefixados com um " - " sai.

ExecStartPost=  → comandos são apenas executado depois que o serviço foi iniciado com  êxito, conforme determinado pelo Type (ou seja, o processo foi iniciado para Type=simple ou Type=idle , o processo sai com sucesso para Type=oneshot , o processo inicial sai com sucesso por Type=forking , " READY=1 " é enviado para Type=notify ou a BusName= tenha sido tomada para Type=dbus ).Note-se que ExecStartPre não podem ser utilizadas para iniciar processos de longa duração. Todos os processos bifurcados off por processos invocados via ExecStartPre serão mortos antes do próximo processo de serviço é executado. 
Observe que, se qualquer um dos comandos especificados no ExecStartPre , ExecStart ou ExecStartPost falhar  ou o tempo limite antes que o serviço é totalmente para cima, a execução continua com comandos especificados no ExecStopPost , os comandos em ExecStop são ignorados. 

ExecReload= → Comandos para executar para desencadear uma recarga de configuração no serviço. Este argumento tem várias linhas de comando, seguindo o mesmo esquema como descrito para ExecStart acima. O uso deste cenário é opcional. Especificador e substituição variável de ambiente é suportada aqui seguindo o mesmo esquema como, por ExecStart. Um, variável adicional ambiente especial está definido: se conhecido, $MAINPID está definido para o processo principal do daemon, e pode ser usado para linhas de comando como o seguinte: 
  / Bin / kill -HUP $ MAINPID 
Note no entanto que recarregar um daemon enviando um sinal (como acontece com o exemplo da linha acima) geralmente não é uma boa escolha, porque esta é uma operação assíncrona e, portanto, não é adequado para pedir recargas de múltiplos serviços uns contra os outros. É altamente recomendável para definir ExecReload a um comando que não só provoca uma recarga configuração do daemon, mas também aguarda de forma síncrona para a conclusão. 

ExecStop=  → Comandos para executar para parar o serviço iniciado através ExecStart . Este argumento tem várias linhas de comando, seguindo o mesmo esquema como descrito para ExecStart acima. O uso deste cenário é opcional. Após os comandos configurados nesta opção são executados, todos os processos restantes para um serviço são terminadas de acordo com o KillMode configuração. Se essa opção não for especificada, o processo é encerrado, enviando o sinal especificado no KillSignal quando parar o serviço é solicitado.Note-se que, geralmente, não é suficiente para especificar um comando para esta definição que só pede o serviço de encerrar (por exemplo, filas alguma forma de sinal de término para ele), mas não esperar por ele para fazê-lo. Uma vez que os processos restantes dos serviços são mortos usando SIGKILL imediatamente após o comando saiu, isso não resultaria em uma parada limpa. O comando especificado deve, portanto, ser uma operação síncrona, não um assíncrono.Note-se que os comandos especificados no ExecStop só são executados quando o serviço foi iniciado com êxito pela primeira vez. Eles não são chamados se o serviço nunca foi iniciado em tudo, ou no caso de a sua start-up falhar, por exemplo, porque qualquer um dos comandos especificados no ExecStart , ExecStartPre ou ExecStartPost falhou  ou expirou. Use ExecStopPost para invocar comandos quando um serviço falha ao iniciar corretamente e é desligado novamente. Recomenda-se utilizar esta definição para comandos que se comunicam com o serviço solicitando rescisão limpo. Quando os comandos especificados com esta opção são executadas deve ser assumido que o serviço ainda é totalmente para cima e é capaz de reagir correctamente a todos os comandos. Para post-mortem etapas de limpeza usar ExecStopPost vez.

ExecStopPost=  → Os comandos adicionais que são executados depois que o serviço for interrompido. Isto inclui os casos em que os comandos configurados no ExecStop foram utilizados, onde o serviço não tem qualquer ExecStop definido, ou onde o serviço foi encerrado inesperadamente. Este argumento tem várias linhas de comando, seguindo o mesmo esquema como descrito para ExecStart . Use uma destas definições é opcional. Especificador e substituição variável de ambiente é suportado. Note-se que ao contrário ExecStop comandos especificados com esta definição são invocados quando um serviço falha ao iniciar corretamente e é desligado novamente. Recomenda-se utilizar esta definição para as operações de limpeza, que será executada mesmo quando o serviço falha ao iniciar corretamente. Comandos configurados com essa configuração precisa ser capaz de operar mesmo que o serviço falhou o arranque a meio caminho e deixou incompleta inicializado dados ao redor. Como os processos do serviço já foram terminado quando os comandos especificados com esta configuração são executados eles não devem tentar se comunicar com eles. 

RestartSec= → Configura o tempo para dormir antes de reiniciar um serviço (como configurado com Restart ). Toma um valor unitário-less, em segundos, ou um valor de intervalo de tempo, tais como "20s 5min". O padrão é de 100ms. 
TimeoutStartSec= → Configura o tempo de espera para start-up. Se um serviço de daemon não sinaliza conclusão start-up dentro do tempo configurado, o serviço será considerado falho e será fechado novamente. Toma um valor unitário-less, em segundos, ou um valor de intervalo de tempo, tais como "20s 5min". Passar " infinity " para desativar a lógica de tempo limite. O padrão é DefaultTimeoutStartSec a partir do arquivo de configuração do gerenciador, exceto quando Type=oneshot é usado, caso em que o tempo limite é desativado por padrão. 

TimeoutStopSec= → Configura o tempo de espera para o batente. Se um serviço é solicitado a parar, mas não terminar no tempo especificado, ela será encerrada à força através SIGTERM , e depois de outro tempo limite de duração igual com SIGKILL. Toma um valor unitário-less, em segundos, ou um valor de intervalo de tempo, tais como "20s 5min". Passar " infinity " para desativar a lógica de tempo limite. O padrão é DefaultTimeoutStopSec= a partir do arquivo de configuração do gerenciador .

TimeoutSec=  → Uma abreviação para configurar tanto TimeoutStartSec= e TimeoutStopSec= para o valor especificado. 

RuntimeMaxSec= → Configura um tempo máximo para o serviço a ser executado. Se for utilizado eo serviço tem sido ativa por mais tempo do que o tempo especificado é encerrado e colocado em um estado de falha. Note que esta definição não tem qualquer efeito sobre Type=oneshot serviços, como eles encerrar imediatamente após a ativação completa. Passar " infinity " (o padrão) para configurar nenhum limite de tempo de execução. 

WatchdogSec= → Configura o tempo limite watchdog para um serviço. O watchdog é ativado quando o start-up é completado. O serviço deve chamar  regularmente com " WATCHDOG=1 " (ou seja, o "ping keep-alive"). Se o tempo entre dois de tais chamadas é maior do que o tempo configurado, em seguida, o serviço é colocado num estado de falha e que irá ser terminada com SIGABRT . Ao definir Restart para on-failure , on-watchdog , on-abnormal ou always , o serviço será reiniciado automaticamente. O tempo configurado aqui será passado para o processo de prestação de serviços celebrado no WATCHDOG_USEC variável de ambiente. Isso permite que os daemons para ativar automaticamente a lógica de ping keep-alive se o suporte watchdog está habilitado para o serviço. Se esta opção for usada, NotifyAccess deve ser definido para abrir o acesso à tomada de notificação prevista pelo systemd. Se NotifyAccess não está definido, será implicitamente definida como main . O padrão é 0, que desativa esse recurso. O serviço pode verificar se o gerente de serviço espera notificações keep-alive de vigilância. 

Restart=  → Configura se o serviço será reiniciado quando o processo de serviço sai, é morto, ou um tempo limite é atingido. O processo de serviço pode ser o processo de serviço principal, mas também pode ser um dos processos referidos com ExecStartPre , ExecStartPost , ExecStop , ExecStopPost ou ExecReload . Quando a morte do processo é um resultado da operação systemd , o serviço não será reiniciado. Tempos limite incluem faltando o cão de guarda "ping keep-alive" prazo e início do serviço, recarregar e parar o tempo limite de operação. Toma um dos no , on-success , on-failure , on-abnormal , on-watchdog , on-abort , ou always . Se definido como no, o serviço não será reiniciado. Se for definido como on-success , ele será reiniciado somente quando o processo de serviço sai limpa. Neste contexto, uma saída limpa significa um código de saída de 0, ou um dos sinais SIGHUP , SIGINT , SIGTERM ou SIGPIPE , e, adicionalmente, os status de saída e sinais especificados em SuccessExitStatus . Se for definido como on-failure , o serviço será reiniciado quando o processo é encerrado com um código de saída diferente de zero, é terminada por um sinal , quando uma operação (como serviço recarregar) vezes, e quando o tempo limite watchdog configurado é acionado. Se for definido como on-abnormal , o serviço será reiniciado quando o processo é encerrado por um sinal , quando uma operação expira, ou quando o tempo limite watchdog é acionado. Se for definido como on-abort , o serviço será reiniciado somente se o processo de serviço sai devido a um sinal não capturado não especificado como um estado de saída limpo. Se for definido como on-watchdog , o serviço será reiniciado somente se o tempo limite watchdog para o serviço expirar. Se definido como always , o serviço será reiniciado independentemente de ele saiu de forma limpa ou não, foi terminada de forma anormal por um sinal, ou bater um tempo limite. 

SuccessExitStatus=  → Recebe uma lista de definições de status de saída que, quando retornado pelo processo de serviço principal, serão considerados termo bem sucedido, além do código de saída bem sucedida Normal 0 e os sinais SIGHUP , SIGINT , SIGTERM e SIGPIPE . definições de status de saída pode ser tanto códigos de saída numéricos ou nomes de sinal de terminação, separados por espaços. 

SuccessExitStatus = 1 2 8 SIGKILL → garante que os códigos de saída 1, 2, 8 e o sinal de terminação SIGKILL terminações serviço limpo são considerados. Esta opção pode aparecer mais de uma vez, caso em que a lista de status de saída bem sucedida é mesclado. Se a cadeia vazia é atribuído a essa opção, a lista é redefinido, todas as atribuições anteriores de esta opção não terá nenhum efeito. 

RestartPreventExitStatus= → Recebe uma lista de definições de status de saída que, quando retornado pelo processo de serviço principal, irá prevenir reinicializações serviço automático, independentemente da configuração reiniciar configurado com Restart . definições de status de saída pode ser tanto códigos de saída numéricos ou nomes de sinal de terminação, e são separados por espaços. O padrão é a lista vazia, de modo que, por padrão, nenhum estado de saída é excluído da lógica de reinício configurado.  

RestartPreventExitStatus = 1 6 SIGABRT → garante que os códigos de saída 1 e 6 e o sinal de terminação SIGABRT não irá resultar em reinicialização automática do serviço. Esta opção pode aparecer mais de uma vez, caso em que a lista de status de prevenção de reinício é mesclado. Se a cadeia vazia é atribuído a essa opção, a lista é redefinida e todas as atribuições anteriores de esta opção não terá nenhum efeito. 

RestartForceExitStatus=  → Recebe uma lista de definições de status de saída que, quando retornado pelo processo de serviço principal, forçarão reinicia serviço automático, independentemente da configuração reiniciar configurado com Restart . O formato argumento é semelhante ao RestartPreventExitStatus .

PermissionsStartOnly= → Toma um argumento booleano. Se for verdade, as opções de execução relacionadas com a permissão, conforme configurado com User e opções semelhantes , são aplicados somente para o processo começou com ExecStart , e não a dos outros ExecStartPre , ExecStartPost , ExecReload , ExecStop e ExecStopPost comandos. Se for falso, a configuração é aplicada a todos os comandos configurados da mesma forma. O padrão é falso. 

RootDirectoryStartOnly= →Toma um argumento booleano. Se for verdade, o diretório raiz, como configurado com o RootDirectory opção , só é aplicado ao processo iniciado com ExecStart , e não a dos outros ExecStartPre , ExecStartPost , ExecReload , ExecStop e ExecStopPost comandos. Se for falso, a configuração é aplicada a todos os comandos configurados da mesma forma. O padrão é falso. 

NonBlocking= → Defina o O_NONBLOCK bandeira para todos os descritores de arquivo passados via ativação baseada em soquete. Se for verdade, todos os descritores de arquivo> = 3 (ou seja, todos, exceto stdin, stdout e stderr) terá o O_NONBLOCK bandeira conjunto e, portanto, estão em modo não-bloqueio. Esta opção é útil apenas em conjunção com uma unidade de terminais . O padrão é falso. 

NotifyAccess= → Controla o acesso à tomada de notificação do status do serviço, como acessível. Toma um dos none (o padrão), main ou all . Se none , não há atualizações de status daemon são aceitos a partir dos processos de atendimento, todas as mensagens de atualização de status são ignorados. Se main , apenas atualizações do serviço, enviadas a partir do processo principal do serviço são aceitos. Se all , todas as atualizações de serviços de todos os membros do grupo de controle da serviço são aceitos. Esta opção deve ser definido para abrir o acesso à tomada de notificação ao usar Type=notify ou WatchdogSec. Se essas opções são usadas, mas NotifyAccess não está configurado, ele será definido implicitamente main . 

Sockets= → Especifica o nome das unidades de soquete este serviço herdarão descritores de arquivos tomada a partir de quando o serviço é iniciado. Normalmente, ele não deve ser necessário utilizar esta definição, como todos os descritores de arquivo de soquete cuja unidade compartilha o mesmo nome que o serviço (sujeito à diferente sufixo do nome da unidade é claro) são passados ​​para o processo gerado. Note-se que os mesmos descritores de arquivo de soquete pode ser passado para múltiplos processos simultaneamente. Observe também que um serviço diferente pode ser ativado no tráfego tomada de entrada do que aquele que é, em última análise configurado para herdar os descritores de arquivo socket. Ou, em outras palavras: o Service definição de .socket unidades não tem de coincidir com o inverso das Sockets configuração do .service ela se refere. Esta opção pode aparecer mais de uma vez, caso em que a lista de unidades de soquete é mesclado. Se a cadeia vazia é atribuído a essa opção, a lista de soquetes é reposto, e todos os usos anteriores desta configuração não terá nenhum efeito. 

FailureAction= → Configurar a ação a ser tomada quando o serviço entra em um estado de falha. Leva os mesmos valores que a definição da unidade StartLimitAction e executa as mesmas ações . O padrão é none . 

FileDescriptorStoreMax=  → Configurar o número de descritores de arquivo pode ser armazenado no gerenciador de serviço  " FDSTORE=1 mensagens". Isso é útil para a implementação de esquemas de reiniciar o serviço onde o estado é serializado para /run e os descritores de arquivo passados para o gerente de serviço, para permitir reiniciado sem perder o estado. O padrão é 0, ou seja, não há descritores de arquivos podem ser armazenados no gerenciador de serviços por padrão. Todos os descritores de arquivo passados ​​para o gerente de serviço de um serviço específico são passados ​​de volta ao processo principal do serviço no próximo reinício do serviço. Quaisquer descritores de arquivo passados ​​para o gerente de serviço são fechadas automaticamente quando POLLHUP ou POLLERR é visto sobre eles, ou quando o serviço está totalmente parado e não há trabalho na fila ou a ser executada por ele. 

USBFunctionDescriptors= → Configurar a localização de um arquivo contendo  descritores, para a implementação de funções de gadgets USB. Isto só é usado em conjunto com uma unidade de soquete com ListenUSBFunction configurado. O conteúdo deste arquivo são gravados no ep0 arquivo depois que ele for aberto. 

USBFunctionStrings= → Configurar a localização de um arquivo contendo FunctionFS USB cordas. Comportamento é semelhante ao USBFunctionDescriptors . 


[Socket]


ListenStream= , ListenDatagram= , ListenSequentialPacket= → Especifica um endereço para escutar para um fluxo ( SOCK_STREAM ), datagrama ( SOCK_DGRAM ), ou pacote sequencial ( SOCK_SEQPACKET socket), respectivamente. O endereço pode ser escrito em vários formatos: Se o endereço começa com uma barra ( " / "), ele é lido como o soquete sistema de arquivos na AF_UNIX família de socket. Se o endereço começa com um símbolo ( " @ "), ele é lido como tomada de nomes abstrato na AF_UNIX família. O " @ " é substituído por um NUL personagem antes de ligação. Se a cadeia de endereço é um número único, que é lido como número da porta para escutar na via IPv6. Dependendo do valor da BindIPv6Only  isso pode resultar em o serviço estar disponível através de ambos IPv6 e IPv4 (padrão) ou apenas via IPv6. Se a cadeia de endereço é uma cadeia no vwxy formato: z, que é lido como IPv4 especificador para ouvir em um vwxy endereço em uma porta z. Se a cadeia de endereço é uma string no formato [x]: y, é lida como o endereço IPv6 x em uma porta y. Note que isso pode tornar o serviço disponível via IPv4, também, dependendo do BindIPv6Only configuração.Note-se que SOCK_SEQPACKET (ieListenSequentialPacket ) só está disponível para AF_UNIX soquetes. SOCK_STREAM (ieListenStream ) quando usado para sockets IP refere-se a sockets TCP, SOCK_DGRAM (ieListenDatagram) para UDP. Essas opções podem ser especificado mais de uma vez, caso o tráfego de entrada que em qualquer um dos soquetes irá desencadear a activação do serviço, e todos os soquetes listados serão passados ​​para oserviço, independente-mente da existência de tráfego de entrada neles ou não. Se a cadeia vazia é atribuído a qualquer uma destas opções, a lista de endereços para escutar é reset, todos os usos anteriores de qualquer uma dessas opções não terá nenhum efeito.Também é possível ter mais de uma unidade de soquete para o mesmo serviço ao usar Service , e o serviço irá receber todos os soquetes configurados em todas as unidades de soquete. Sockets configurados em uma unidade são passados ​​na ordem de configuração, mas nenhuma ordenação entre as unidades de soquete for especificado. Se um endereço IP é usado aqui, é muitas vezes desejável para ouvir sobre ele antes que a interface é configurada no está instalado e funcionando, e até mesmo independentemente de se ele vai ser instalado e funcionando em qualquer ponto. Para lidar com isso, é recomendado para definir o FreeBind opção descrita abaixo. 

ListenFIFO= → Especifica um FIFO sistema de arquivos para escutar. Esta espera um caminho de sistema de arquivo absoluto como argumento. Comportamento contrário é muito semelhante ao ListenDatagram directiva acima. 

ListenSpecial= → Especifica um arquivo especial no sistema de arquivos para escutar. Esta espera um caminho de sistema de arquivo absoluto como argumento. Comportamento contrário é muito semelhante ao ListenFIFO directiva acima. Use-a para abrir os nós de dispositivos de caracteres, bem como arquivos especiais em /proc e /sys . 

ListenNetlink= → Especifica uma família Netlink para criar um soquete para a escutar. Esta espera uma corda curta referindo-se ao AF_NETLINK nome de família (como audit ou kobject-uevent ) como argumento, opcionalmente sufixo por um espaço em branco seguido por um inteiro grupo de multicast. Comportamento contrário é muito semelhante ao ListenDatagram. 

ListenMessageQueue= → Especifica um nome de fila de mensagens POSIX para escutar. Esta espera um nome de fila de mensagem válida (ou seja, começando com /). Comportamento contrário é muito semelhante ao ListenFIFO= directiva acima. No Linux descritores de fila de mensagens são realmente descritores de arquivos e pode ser herdada entre processos. 

ListenUSBFunction= → Especifica um  local endpoint para escutar, para  a implementação de funções de gadgets USB. Esta espera um caminho de sistema de arquivo absoluto como o argumento. Comportamento contrário é muito semelhante ao ListenFIFO directiva acima. Usar isso para abrir o endpoint FunctionFS ep0 . Ao usar esta opção, o serviço activado tem que ter as USBFunctionDescriptors e USBFunctionStrings opções definido. 
SocketProtocol= → Leva um um dos udplite ou sctp . Especifica um protocolo de socket (IPPROTO_UDPLITE ) UDP-Lite ( IPPROTO_SCTP tomada SCTP), respectivamente. 
BindIPv6Only= → Toma um de default , both ou ipv6-only . Controla a opção de soquete IPV6_V6ONLY. Se both , soquetes IPv6 com destino será acessível via IPv4 e IPv6. Se ipv6-only , eles serão acessíveis somente via IPv6. O valor padrão global do sistema é usado, como controlado por /proc/sys/net/ipv6/bindv6only , que por padrões de volta para o equivalente a both . 

Backlog= → Leva um argumento inteiro sem sinal. Especifica o número de conexões a fila que ainda não foram aceites. Esta definição só tem importância para o córrego e soquetes de pacotes sequenciais. Padrões para SOMAXCONN (128). 

BindToDevice= → Especifica um nome de interface de rede para ligar esta tomada para. Se definido, o tráfego só serão aceites a partir das interfaces de rede especificados. Isto controla a opção de socket SO_BINDTODEVICE . Se esta opção é utilizada, uma dependência automática a partir desta unidade de terminais na unidade de dispositivo de interface de rede  é criado. Note-se que a definição desse parâmetro pode resultar em dependência adicional a ser adicionado ao aparelho. 

SocketUser= , SocketGroup= → Leva um nome de usuário / grupo UNIX. Quando especificado, todos os soquetes AF_UNIX e nós FIFO no sistema de arquivos são de propriedade do usuário e grupo especificado. Se não estiver definida, os nós são de propriedade do usuário root / grupo  ou o usuário invocando / grupo. Se apenas um usuário está especificado, mas nenhum grupo, então o grupo é derivado do grupo padrão do usuário. 

SocketMode= → Se escutando em um soquete sistema de arquivos ou FIFO, esta opção especifica o modo de acesso ao sistema de arquivos usado ao criar o nó de arquivo. Toma um modo de acesso em notação octal. O padrão é 0666. 

DirectoryMode= → Se escutando em um soquete sistema de arquivos ou FIFO, os diretórios pai são criadas automaticamente, se necessário. Esta opção especifica o modo de acesso do sistema de arquivos usado na criação desses diretórios. Toma um modo de acesso em notação octal. O padrão é 0755. 

Accept= → Toma um argumento booleano. Se for verdade, uma instância de serviço é gerado para cada conexão de entrada e só tomada de ligação é passada para ele. Se false, todas as próprias bases de escuta são passados ​​para a unidade de serviço começou, e apenas uma unidade de serviço é gerada para todas as ligações (também veja acima). Este valor é ignorado para sockets de datagramas e FIFOs onde uma única unidade de serviço manipula incondicionalmente todo o tráfego de entrada. O padrão é false . Por motivos de desempenho, recomenda-se para escrever novos daemons apenas em uma forma que é adequado para Accept=false . Um daemon que escuta em um AF_UNIX soquete . No entanto, não deverá desvincular a tomada de um sistema de arquivos. Se o soquetes ficou com Accept=false , pode fazer o sockets  ficar com Accept=true set. Definir Accept=true é útil principalmente para permitir daemons projetados para uso de trabalho não modificada com a ativação tomada systemd. Para conexões IPv4 e IPv6, o REMOTE_ADDR variável de ambiente irá conter o endereço IP remoto e REMOTE_PORT conterá a porta remota. Este é o mesmo que o formato usado pelo CGI. Para SOCK_RAW, o porto é o protocolo IP. 

Writable= → Toma um argumento booleano. Só pode ser usado em conjunto com ListenSpecial . Se for verdade, o arquivo especial especificado é aberto no modo de leitura e escrita, se for falso, em modo de somente leitura. O padrão é falso. 
MaxConnections= → O número máximo de conexões a instâncias de serviços executados simultaneamente para, quando Accept=true é definido. Se mais conexões simultâneas estão chegando, eles vão ser recusado até pelo menos uma conexão existente é encerrado. Essa configuração não tem efeito sobre soquetes configurados com Accept=false soquetes ou datagramas. O padrão é 64. 

KeepAlive= → Toma um argumento booleano. Se for verdade, a pilha TCP / IP irá enviar uma mensagem de manter vivo após 2h (dependendo da configuração do /proc/sys/net/ipv4/tcp_keepalive_time ) para todos os fluxos TCP aceites sobre este socket. Isto controla a opção de socket SO_KEEPALIVE o padrão é false . 
KeepAliveTimeSec= → Leva tempo (em segundos) como argumento. A conexão deve permanecer inactivo antes de TCP começa a enviar sondas keepalive. Isto controla a opção de socket TCP_KEEPIDLE  valor Padrões é 7200 segundos (2 horas). 
KeepAliveIntervalSec= → Leva tempo (em segundos) como argumento entre as sondas de manutenção de atividade individuais, se o SO_KEEPALIVE opção de soquete foi definida sobre este socket. Isto controla a opção de socket TCP_KEEPINTVL valor Padrões é de 75 segundos. 

KeepAliveProbes= → Toma um número inteiro como argumento. É o número de sondas não confirmadas para enviar antes de considerar a ligação mortos e notificar a camada de aplicação. Isto controla a opção de socket TCP_KEEPCNT valor Padrões é 9.

NoDelay= → Toma um argumento booleano. O algoritmo do TCP Nagle funciona combinando uma série de pequenas mensagens de saída e enviá-los todos de uma vez. Isto controla a opção de socket TCP_NODELAY padrões para false . 

Priority= → Toma um argumento inteiro controlar a prioridade para todo o tráfego enviado a partir deste socket. Isto controla a opção de socket SO_PRIORITY Seta. 

DeferAcceptSec= → Leva tempo (em segundos) como argumento. Se definido, o processo de escuta serão despertados somente quando os dados chegam no soquete, e não imediatamente quando a conexão é estabelecida. Quando esta opção for definida, o TCP_DEFER_ACCEPT opção de soquete será usado , e o kernel irá ignorar pacotes ACK iniciais sem quaisquer dados. O argumento especifica a quantidade aproximada de tempo que o kernel deve esperar por dados de entrada antes de cair de volta para o comportamento normal de honrar ACK pacotes vazios. Esta opção é benéfica para os protocolos em que o cliente envia os dados pela primeira vez (por exemplo, HTTP, em contraste com SMTP), porque o processo servidor não será acordado desnecessariamente antes de tomar qualquer ação. Se o cliente também usa o TCP_DEFER_ACCEPT opção, a latência da conexão inicial pode ser reduzida, porque o kernel irá enviar dados no pacote final, estabelecendo a conexão (o terceiro pacote no "three-way handshake"). Desativada por padrão. 

ReceiveBuffer= , SendBuffer= → Toma um argumento inteiro controlar os tamanhos de receber ou enviar buffer deste socket, respectivamente. Este controla as opções de socket SO_RCVBUF e SO_SNDBUF . Os sufixos habituais K, M, G e são suportados são entendidas à base de 1024. 

IPTOS= → Toma um argumento inteiro controlar o campo IP Tipo de Serviço para pacotes gerados a partir deste socket. Isto controla a opção de socket IP_TOS  ou uma seqüência numérica ou um de low-delay , throughput , reliability ou low-cost podem ser especificados. 

IPTTL= → Toma um argumento inteiro controlar o campo IPv4 Time-To-Live / IPv6 Hop-Count para pacotes gerados a partir deste socket. Isso define as opções de socket IP_TTL / IPV6_UNICAST_HOPS .

Mark= → Toma um valor inteiro. Controla a marca firewall de pacotes gerados por esta tomada. Isto pode ser usado na lógica firewall para filtrar pacotes de esta tomada. Isso define a opção de socket SO_MARK. 

ReusePort= → Aceita um valor booleano. Se for verdade, permite que múltiplos a esta porta TCP ou UDP. Isto controla a opção de socket SO_REUSEPORT. 

SmackLabel= , SmackLabelIPIn= , SmackLabelIPOut= → Toma um valor de cadeia. Controla os atributos estendidos " security.SMACK64 ", " security.SMACK64IPIN " e " security.SMACK64IPOUT ", respectivamente, ou seja, a etiqueta de segurança do FIFO, ou a etiqueta de segurança para as conexões de entrada ou saída do soquete, respectivamente.

SELinuxContextFromNet= → Toma um argumento booleano. Quando verdadeiro, systemd tentará descobrir o rótulo SELinux utilizado para o serviço instanciado a partir da informação transmitida pelos pares através da rede. Note que apenas o nível de segurança é utilizado a partir das informações fornecidas pelos pares. Outras partes do contexto SELinux resultante originam a partir de qualquer binário alvo que é eficazmente desencadeado pela unidade de terminais ou a partir do valor do SELinuxContext opção. Esta opção de configuração só afeta soquetes com Accept modo definido como " true ". Note também que esta opção é útil apenas quando a política MLS / MCS SELinux é implantado. O padrão é " false ". 

PipeSize= → Toma um tamanho em bytes. Controla o tamanho do buffer de tubulação de FIFOs configurados nesta unidade soquete.  Os sufixos habituais K, M, G e são suportados são entendidas à base de 1024. 

MessageQueueMaxMessages= , MessageQueueMessageSize= → Estas duas configurações tenham valores inteiros e controlar o campo mq_maxmsg ou o campo mq_msgsize, respectivamente, ao criar a fila de mensagens. Note-se que, quer nenhum ou ambas as seguintes variáveis ​​devem ser ajustados. 

FreeBind= → Aceita um valor booleano. Controla se o soquete podem ser vinculados a endereços IP não-locais. Isso é útil para configurar soquetes de escuta em endereços IP específicos antes que esses endereços IP são configurados com sucesso em uma interface de rede. Isso define a opção de socket IP_FREEBIND. Por motivos de robustez, recomenda-se usar esta opção sempre que você ligar um socket a um endereço IP específico. O padrão é false . 

Transparent= → Aceita um valor booleano. Controla a opção de soquete IP_TRANSPARENT. O padrão é false . 

Broadcast= → Aceita um valor booleano. Isto controla a opção de socket SO_BROADCAST, que permite datagramas de difusão para ser enviado a partir deste socket. O padrão é false . 

PassCredentials= → Aceita um valor booleano. Isto controla a opção de socket SO_PASSCRED, que permite AF_UNIX soquetes para receber as credenciais do processo de envio de uma mensagem ancilar. O padrão é false . 

PassSecurity= → Aceita um valor booleano. Este controla a opção de soquete SO_PASSSEC, que permite AF_UNIX tomadas para receber o contexto do processo de envio de uma mensagem de segurança em acessória. O padrão é false .

TCPCongestion= → Toma um valor de cadeia. Controla o algoritmo de TCP congestionamento usado por este socket. Deve ser um dos "Westwood", "veno", "cúbico", "LP" ou qualquer outro algoritmo disponível suportado pela pilha IP. Esta definição aplica-se apenas a tomadas de transmissão. 

ExecStartPre= , ExecStartPost= → Toma uma ou mais linhas de comando, que são executados antes ou depois dos soquetes de escuta / FIFOs são criados e vinculados, respectivamente. O primeiro sinal da linha de comando deve ser um nome de arquivo absoluto, seguido por argumentos para o processo. Múltiplas linhas de comando pode ser especificado a seguir o mesmo esquema que o utilizado para ExecStartPre de arquivos de unidade de serviço. 

ExecStopPre= , ExecStopPost= → Os comandos adicionais que são executados antes ou depois dos soquetes de escuta / FIFO estão fechados e removidos, respectivamente. Múltiplas linhas de comando pode ser especificado a seguir o mesmo esquema que o utilizado para ExecStartPre de arquivos de unidade de serviço. 

TimeoutSec= → Configura o tempo de espera para os comandos especificados no ExecStartPre , ExecStartPost , ExecStopPre e ExecStopPost para terminar. Se um comando não sair dentro do tempo configurado, o soquete será considerado falhou e ser desligado novamente. Todos os comandos ainda em execução será encerrada à força através SIGTERM , e depois outro atraso desta vez com SIGKILL .  Toma um valor unitário-less, em segundos, ou um valor de intervalo de tempo, tais como "20s 5min". Passar " 0 " para desativar a lógica de tempo limite. O padrão é DefaultTimeoutStartSec a partir do arquivo de configuração do gerenciador 

Service= → Especifica o nome da unidade de serviços para ativar no tráfego de entrada. Esta definição só é permitida para soquetes com Accept=no . O padrão é o serviço que leva o mesmo nome que o socket . Na maioria dos casos, não deve ser necessário usar esta opção. Note-se que a definição desse parâmetro pode resultar em dependência adicional a ser adicionado ao aparelho . 

RemoveOnStop= → Toma um argumento booleano. Se ativado, os nós de arquivos criados por esta unidade de soquete são removidos quando se está parado. Isso se aplica a AF_UNIX tomadas no sistema de arquivos, filas de mensagens POSIX, FIFOs, bem como quaisquer links simbólicos para eles configurados com Symlinks . Normalmente, ele não deve ser necessário para usar esta opção, e não é recomendado como serviços pode continuar a funcionar depois da unidade de soquete foi encerrado e ele ainda deve ser possível comunicar com eles através do seu nó de sistema de arquivos. O padrão é off. 

Symlinks= → Recebe uma lista de caminhos de sistema de arquivo. Os caminhos especificados serão criados como links simbólicos para o caminho do socket AF_UNIX ou caminho FIFO desta unidade soquete. Se esta definição for usada, apenas uma tomada AF_UNIX no sistema de arquivos ou um FIFO pode ser configurado para a unidade de soquete. Use esta opção para gerenciar um ou mais nomes de alias simbolicamente para um soquete, ligando seu ciclo de vida juntos. O padrão é a lista vazia. 

FileDescriptorName= → Atribui um nome a todos os descritores de arquivos desta unidade tomada encapsula. Isso é útil para ajudar os serviços ativados identificar descritores de arquivos específicos, se vários fds são passados.  Os nomes podem conter qualquer caractere ASCII, mas deve excluir caracteres de controle e " : ", e deve ser, no máximo, 255 caracteres de comprimento. Se essa configuração não é usado, o nome descritor de arquivo padrão para o nome da unidade de terminais, incluindo a sua .socket sufixo. 

TriggerLimitIntervalSec= , TriggerLimitBurst= → Configura um limite de quantas vezes esta unidade soquete Meu ser ativado dentro de um intervalo de tempo específico. O TriggerLimitIntervalSec pode ser usado para configurar a duração do intervalo de tempo nas unidades de tempo habituais " us ", " ms ", " s ", " min ", " h ", ... e padrões para 2s . O TriggerLimitBurst configuração tem um valor inteiro positivo e especifica o número de ativações permitidas por intervalo de tempo, e o padrão é 200 para Accept=yes soquetes (assim, por padrão, permitindo 200 ativações por 2s), e 20 de outra forma (20 ativações por 2s). Defina para 0 para desabilitar qualquer forma de taxa de gatilho limitante. Se o limite for atingido, a unidade de suportes fêmea está colocado num estado de falha, e não irá ser mais connectible até ser reiniciado. Note que este limite é aplicada antes da ativação do serviço é enfileirado. 


[BusName]


Para os serviços que adquirem um nome no bus do sistema DBus, utilizar Type= dbuse definir BusName em conformidade. O serviço não deve bifurcar (daemonize). systemd irá considerar o serviço para ser inicializado uma vez que o nome tenha sido adquirido no bus do sistema.


[Mount]


x-systemd.requires= → Configura um Requires e um After dependência entre a unidade de montagem criada e outra unidade systemd, como um dispositivo ou unidade de montagem. O argumento deve ser um nome de unidade, ou um caminho absoluto para um nó de dispositivo ou ponto de montagem. Esta opção pode ser especificada mais de uma vez. Esta opção é particularmente útil para as declarações de pontos de montagem que precisam de um dispositivo adicional de ser em torno (como um dispositivo de jornal externo para sistemas de arquivos jornal) ou um adicional de montagem de estar no lugar (como um sistema de arquivo de sobreposição que mescla vários pontos de montagem) . 

x-systemd.requires-mounts-for= → Configura um RequiresMountsFor dependência entre a unidade de montagem criada e outras unidades de montagem. O argumento deve ser um caminho absoluto. Esta opção pode ser especificada mais de uma vez.

x-systemd.automount= → Uma unidade de montagem automática será criada para o sistema de arquivos.

x-systemd.idle-timeout= → Configura o tempo limite de inactividade da unidade de montagem automática. 

x-systemd.device-timeout= → Configurar quanto tempo o systemd deve esperar por um dispositivo para mostrar-se antes de desistir de uma entrada /etc/fstab . Especificar um tempo em segundos ou anexar explicitamente uma unidade como " s ", " min ", " h ", " ms ".Note que esta opção só pode ser usada em /etc/fstab , e será ignorado quando parte das Options configuração em um arquivo de unidade. 
noauto , auto 
Com noauto , esta montagem não será adicionado como uma dependência para local-fs.target ou remote-fs.target . Isto significa que não será montado automaticamente durante o arranque, a menos que seja puxado por alguma outra unidade. A auto opção tem o significado oposto e é o padrão. 

Nofail= → Com nofail , esta montagem será apenas queria, não é necessário, por local-fs.target ou remote-fs.target . Isto significa que a inicialização irá continuar, mesmo se este ponto de montagem não está montado com êxito. 

x-initrd.mount= → Um sistema de ficheiros adicionais para serem montados no initramfs. 

What= → Toma um caminho absoluto de um nó de dispositivo, arquivo ou outro recurso de montar.  Se isso se refere a um nó de dispositivo, uma dependência da respectiva unidade dispositivo é criado automaticamente.  Esta opção é obrigatória. 

Where= → Toma um caminho absoluto de um diretório do ponto de montagem. Se o ponto de montagem não existe, no momento da montagem, ele será criado. Esta cadeia tem de ser refletido na unidade de nome de arquivo.  Esta opção é obrigatória. 

Type= → Pega uma string para o tipo de sistema de arquivos. Essa configuração é opcional. 

Options= → Opções de montagem para usar durante a montagem. Isso leva uma lista separada por vírgulas de opções. Essa configuração é opcional. 

SloppyOptions= → Toma um argumento booleano. Se for verdade, a análise das opções especificadas na Options é relaxado, e desconhecido opções de montagem são tolerados. Isto corresponde com 's -s switch. O padrão é off. 

DirectoryMode= → Diretórios de pontos de montagem (e qualquer diretório pai) são criados automaticamente, se necessário. Esta opção especifica o modo de acesso do sistema de arquivos usado na criação desses diretórios. Toma um modo de acesso em notação octal. O padrão é 0755. 

TimeoutSec= → Configura o tempo de espera para o comando de montagem ao fim. Se um comando não sair dentro do tempo configurado, o suporte será considerada falhou e ser desligado novamente. Todos os comandos ainda em execução será encerrada à força através SIGTERM , e depois outro atraso desta vez com SIGKILL .  Toma um valor unitário-less, em segundos, ou um valor de intervalo de tempo, tais como "20s 5min". Passe 0 para desativar a lógica de tempo limite. O valor padrão é definido a partir do arquivo de configuração do gerenciador DefaultTimeoutStart variável. 


[Automount]



Where= → Toma um caminho absoluto de um diretório do ponto de montagem automática. Se o ponto de montagem automática não existe no momento que o ponto de montagem automática estiver instalado, ele será criado. Esta cadeia tem de ser refletido na unidade de nome de arquivo.  Esta opção é obrigatória. 

DirectoryMode= → Diretórios de pontos de automount (e qualquer diretório pai) são criados automaticamente, se necessário. Esta opção especifica o modo de acesso do sistema de arquivos usado na criação desses diretórios. Toma um modo de acesso em notação octal. O padrão é 0755. 

TimeoutIdleSec= →Configura um tempo ocioso. Uma vez que a montagem foi inativo durante o tempo especificado, systemd tentará desmontar. Toma um valor unitário-less, em segundos, ou um valor de intervalo de tempo, tais como "20s 5min". Passe 0 para desativar a lógica de tempo limite. O tempo limite é desativado por padrão. 



[Swap]



noauto , auto= → Com noauto , a unidade de comutação não será adicionado como uma dependência para swap.target . Isto significa que não será activado automaticamente durante o arranque, a menos que seja puxado por alguma outra unidade. A auto opção tem o significado oposto e é o padrão. 

Nofail=  → Com nofail , a unidade de swap será só quis, não exigido pela swap.target . Isto significa que a inicialização irá continuar, mesmo se este dispositivo swap não é ativado com sucesso. 

What= → Toma um caminho absoluto de um nó de dispositivo ou arquivo a ser usado para paginação. Se isso se refere a um nó de dispositivo, uma dependência da respectiva unidade dispositivo é criado automaticamente.  Se isto se refere a um arquivo, uma dependência da respectiva unidade de montagem é criado automaticamente. Esta opção é obrigatória. 

Priority= → prioridade de swap para usar quando ativar o dispositivo de troca ou arquivo. Isso leva um inteiro. Esta configuração é opcional e ignorada quando a prioridade é definida por pri= no Options= chave. 

Options= → Pode conter uma cadeia de opções para o dispositivo swap. Isto pode ser usado para controlar as opções de descarte entre outras funcionalidades, se o dispositivo de permuta de suporte suporta a guarnição de descarte ou operação. 

TimeoutSec= → Configura o tempo de espera para o comando swapon ao fim. Se um comando não sair dentro do tempo configurado, a troca será considerada falhou e ser desligado novamente. Todos os comandos ainda em execução será encerrada à força através SIGTERM , e depois outro atraso desta vez com SIGKILL . Toma um valor unitário-less, em segundos, ou um valor de intervalo de tempo, tais como "20s 5min". Passar " 0 " para desativar a lógica de tempo limite. O padrão é DefaultTimeoutStartSec a partir do arquivo de configuração do gerenciador


[Timer]



OnActiveSec= , OnBootSec= , OnStartupSec= , OnUnitActiveSec= , OnUnitInactiveSec= → Define temporizadores monótono em relação a diferentes pontos de partida: OnActiveSec . Define um temporizador em relação ao momento em que o temporizador em si é ativado OnBootSec define um temporizador em relação a quando a máquina foi arrancado. OnStartupSec define um temporizador em relação a quando systemd foi iniciado pela primeira vez . OnUnitActiveSec define um temporizador em relação a quando a unidade do temporizador está ativando foi ativada pela última vez. OnUnitInactiveSec define um temporizador em relação a quando a unidade do temporizador está ativando foi o último desativado. Várias directivas podem ser combinados da mesma e de diferentes tipos. Por exemplo, pela combinação de OnBootSec e OnUnitActiveSec , é possível definir um temporizador que decorre em intervalos regulares e activa um serviço específico de cada vez Os argumentos para as directivas são intervalos de tempo configurados em segundos. Exemplo: "OnBootSec = 50" significa 50 anos após a inicialização. O argumento pode também incluir unidades de tempo. Exemplo: "30min OnBootSec = 5h" significa 5 horas e 30 minutos após a inicialização.  Se um temporizador configurado com OnBootSec ou OnStartupSec já está no passado, quando a unidade de temporizador é ativado, ele irá decorrer imediatamente e a unidade configurada é iniciada. Este não é o caso para temporizadores definidas nas outras directivas. Estes são os temporizadores monótonas, independente do tempo de relógio de parede e fusos horários. Se o computador estiver temporariamente suspensa, o relógio monótona pára também.  Se a cadeia vazia é atribuído a qualquer uma destas opções, a lista dos temporizadores é reposto, e todas as atribuições anteriores não terá nenhum efeito. Note-se que os temporizadores não necessariamente expiram no momento exato configurado com essas configurações, como eles estão sujeitos à AccuracySec. 

OnCalendar= → Define em tempo real (ou seja, wallclock) temporizadores com expressões de eventos de calendário. Caso contrário, a semântica é semelhante ao OnActiveSec e configurações relacionadas. Note-se que os temporizadores não necessariamente expiram no momento exato configurado com essa configuração, pois ela está sujeita à AccuracySec. 

AccuracySec= → Especificar a precisão do temporizador deve mediar com. O padrão é 1min. O temporizador está programado para decorrer dentro de uma janela de tempo começando com o tempo especificado no OnCalendar , OnActiveSec , OnBootSec , OnStartupSec , OnUnitActiveSec ou OnUnitInactiveSec e terminando o tempo configurado com AccuracySec mais tarde. Dentro desta janela de tempo, o tempo de expiração será colocado em uma posição, randomizado específico do anfitrião, mas estável, que é sincronizado entre todas as unidades temporizador locais. Isto é feito a fim de otimizar o consumo de energia para suprimir CPU wake-ups desnecessários. Para obter melhor precisão, defina esta opção para 1us. Note que o temporizador está ainda sujeita à folga temporizador configurado via   TimerSlackNSec definição.  Para otimizar o consumo de energia, certifique-se de definir esse valor mais alto possível e tão baixo quanto necessário.

RandomizedDelaySec= → Atrasar o temporizador por um selecionados aleatoriamente montante, uniformemente distribuída de tempo entre 0 e o valor de tempo especificado. O padrão é 0, indicando que nenhum atraso aleatório deve ser aplicada. Cada unidade temporizador irá determinar esse atraso aleatoriamente cada vez que é iniciado, e o atraso será simplesmente adicionada no topo da próxima vez decorrido determinado. Isto é útil para esticar envio de eventos de temporizador configurados de forma semelhante ao longo de um determinado período de tempo montante, para evitar que todo o fogo, ao mesmo tempo, possivelmente resultando na congestão de recursos. Note-se a relação com AccuracySec acima: o último permite que o gerente de serviço verifique eventos do timer dentro de um intervalo de tempo especificado, a fim de minimizar wakeups, o ex-faz o oposto: ela se estende eventos de tempo ao longo de um intervalo de tempo, para fazer com que seja improvável que eles disparar simultaneamente. Se RandomizedDelaySec e AccuracySec são utilizados em conjunto, o primeiro atraso aleatório é adicionado, e em seguida, o resultado é, possivelmente, ainda mais deslocada para  com outros eventos de temporizador que acontecem no sistema. Como mencionado acima AccuracySec padrão para 1min e RandomizedDelaySec a 0. A fim de esticar optimamente eventos de tempo ao longo de um determinado intervalo de tempo, certifique-se definir RandomizedDelaySec para um valor superior, e AccuracySec=1us . 

Unit= → A unidade para ativar quando o tempo passar. O argumento é um nome de unidade, cujo sufixo não é " .timer ". Se não for especificado, este valor padrão para um serviço que tem o mesmo nome que a unidade timer, exceto para o sufixo. É recomen-dável que o nome da unidade que é ativado e o nome da unidade da unidade de temporizador são nomeados de forma idêntica, exceto pelo sufixo. 

Persistent= → Toma um argumento booleano. Se for verdade, o momento em que a unidade de serviço foi o último acionado é armazenado no disco. Quando o temporizador é activado, a unidade de serviço é acionado imediatamente se ele teria sido disparado pelo menos uma vez durante o tempo em que o temporizador foi inativo. Isso é útil para recuperar o atraso em corridas perdidas do serviço quando a máquina foi desligada. Note que esta definição só tem um efeito sobre temporizadores configurados com OnCalendar . O padrão é false . 

WakeSystem= → Toma um argumento booleano. Se for verdade, um temporizador que decorre fará com que o sistema para retomar a partir de suspensão, ele deve ser suspenso e, se o sistema suporta esta. Note que esta opção só irá certificar-se de que o sistema retoma nos momentos adequados, não vai cuidar de suspendê-lo novamente depois de todo o trabalho que está a ser feito está terminado. O padrão é false .

RemainAfterElapse= → Toma um argumento booleano. Se for verdade, um temporizador decorrido vai ficar carregado, e seu estado permanece queriable. Se for falso, uma unidade de temporizador decorrido que não pode terminar mais é descarregado. Desativar essa opção é particularmente útil para unidades temporizador transitórias que devem desaparecer depois do primeiro decorrer. Observe que essa configuração tem um efeito sobre repetidamente iniciar uma unidade de temporização que apenas decorre uma vez: se RemainAfterElapse estiver ligado, ele não será iniciado novamente, e está garantido para passar apenas uma vez. No entanto, se RemainAfterElapse estiver desligado, ele pode ser reiniciada se já estiver decorrido, e, assim, ser acionado várias vezes. O padrão é yes . 


[Path]


PathExists= , PathExistsGlob= , PathChanged= , PathModified= , DirectoryNotEmpty= → Define os caminhos para monitorar certas mudanças: PathExists pode ser usado para assistir a mera existência de um arquivo ou pasta. Se o arquivo especificado existe, a unidade configurada é ativado. PathExistsGlob funciona de forma semelhante, mas verifica a existência de pelo menos um arquivo correspondente ao padrão englobamento especificado. PathChanged pode ser usado para assistir a um arquivo ou diretório e ativar o aparelho configurado sempre Isso muda. Ele não está ativado em cada gravação para o arquivo assistiu mas é ativado se o arquivo que foi aberto para escrita fica fechado. PathModified é semelhante, mas além disso, ele é ativado também nas gravações simples para o arquivo observou. DirectoryNotEmpty podem ser utilizados para assistir a um diretório e ativar o aparelho configurado sempre que contém pelo menos um arquivo. Os argumentos destas directivas devem ser caminhos absolutos do sistema de arquivos. Várias directivas podem ser combinados, do mesmo e de diferentes tipos, para assistir a vários caminhos. Se a cadeia vazia é atribuído a qualquer uma destas opções, a lista de caminhos para assistir é reposto, e quaisquer trabalhos anteriores de essas opções não terá qualquer efeito.  Se um caminho já existe (no caso de PathExists e PathExistsGlob ) ou um directório já não está vazia (no caso de DirectoryNotEmpty ) no momento em que a unidade de caminho é activado, então a unidade configurada é imediatamente activado como bem. Algo semelhante não se aplica a PathChanged e PathModified . Se o próprio caminho ou qualquer um dos diretórios que contêm não são acessíveis, systemd vai assistir para alterações de permissão e observe que as condições são satisfeitas quando as permissões permitir isso. 

Unit= → A unidade para ativar quando qualquer um dos caminhos configurados muda. O argumento é um nome de unidade, cujo sufixo não é " .path ". Se não for especificado, este valor padrão para um serviço que tem o mesmo nome que a unidade caminho, exceto para o sufixo.  É recomendável que o nome da unidade que é ativado e o nome da unidade da unidade caminho são nomeados idênticos, exceto para o sufixo. 

MakeDirectory= → Toma um argumento booleano. Se for verdade, os diretórios para assistir são criados antes de assistir. Esta opção é ignorada para PathExists configurações. O padrão é false . 

DirectoryMode= → Se MakeDirectory está habilitado, use o modo especificado aqui para criar os diretórios em questão. Toma um modo de acesso em notação octal. O padrão é 0755 . 


[Slice]


Unidades slice ganha automaticamente dependências do tipo After= e Requires= em sua unidade de slice pai imediato → A menos que DefaultDependencies=false é usada no " [Unit] " seção, unidades slice terá implicitamente dependências do tipo Conflicts= e Before= sobre shutdown.target . Estes asseguram que as unidades de slice são removidos antes do desligamento do sistema. Apenas as unidades slice envolvidos com bota cedo ou desligamento do sistema final deve desativar esta opção. 


[Scope]


A menos que DefaultDependencies=false é usada, as unidades de escopo terá implicitamente dependências do tipo Conflicts= e Before= sobre shutdown.target . Estes asseguram que as unidades de escopo são removidos antes de desligar o sistema. Apenas as unidades de escopo envolvidos com bota cedo ou desligamento do sistema final deve desativar esta opção. 
Estas informações foram tiradas do manual systemd para mais informação acesse esse link (https://www.freedesktop.org/software/systemd/man/systemd.unit.html)
Bom agora que você já sabe o que quer dizer cada unidade, vai ser mais facil de entender os comandos do systemd.


Comandos systemd e systemctl


Systemd –-system →  este comando checa o sistema e mostra se tem algum serviço parado, Obs.:. você só consegue usar esse comando, se for root, detalhe depois da checagem ele reinicia o sistema.
 Uma ferramenta mais eficaz de acessar o systemd é o systemctl, 

systemctl →  mostra uma lista dos serviços 
sidney@debian:~$ systemctl
  UNIT                                 LOAD   ACTIVE SUB       DESCRIPTION
  proc-sys-fs-binfmt_misc.automount    loaded active waiting   Arbitrary Executable File Formats Fil
  sys-devices-pci0000:00-0000:00:0f.1-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda1.device loaded ac
  sys-devices-pci0000:00-0000:00:0f.1-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda2.device loaded ac
  sys-devices-pci0000:00-0000:00:0f.1-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda5.device loaded ac
  sys-devices-pci0000:00-0000:00:0f.1-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda6.device loaded ac
  sys-devices-pci0000:00-0000:00:0f.1-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda7.device loaded ac
  sys-devices-pci0000:00-0000:00:0f.1-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda8.device loaded ac
  sys-devices-pci0000:00-0000:00:0f.1-ata1-host0-target0:0:0-0:0:0:0-block-sda.device loaded active 
  sys-devices-pci0000:00-0000:00:0f.1-ata1-host0-target0:0:1-0:0:1:0-block-sdb-sdb1.device loaded ac
  sys-devices-pci0000:00-0000:00:0f.1-ata1-host0-target0:0:1-0:0:1:0-block-sdb-sdb5.device loaded ac
  sys-devices-pci0000:00-0000:00:0f.1-ata1-host0-target0:0:1-0:0:1:0-block-sdb.device loaded active 
  sys-devices-pci0000:00-0000:00:11.5-sound-card0.device loaded active plugged   VT8233/A/8235/8237 
  sys-devices-pci0000:00-0000:00:12.0-net-eth0.device loaded active plugged   VT6102/VT6103 [Rhine-I
  sys-devices-platform-floppy.0-block-fd0.device loaded active plugged   /sys/devices/platform/flopp
  sys-devices-platform-serial8250-tty-ttyS2.device loaded active plugged   /sys/devices/platform/ser
  sys-devices-platform-serial8250-tty-ttyS3.device loaded active plugged   /sys/devices/platform/ser
  sys-devices-pnp0-00:05-tty-ttyS0.device loaded active plugged   /sys/devices/pnp0/00:05/tty/ttyS0
  sys-devices-pnp0-00:06-tty-ttyS1.device loaded active plugged   /sys/devices/pnp0/00:06/tty/ttyS1
  sys-module-fuse.device               loaded active plugged   /sys/module/fuse
  sys-subsystem-net-devices-eth0.device loaded active plugged   VT6102/VT6103 [Rhine-II]
  -.mount                                         loaded active mounted   /
  dev-hugepages.mount                  loaded active mounted   Huge Pages File System
  dev-mqueue.mount                      loaded active mounted   POSIX Message Queue File System
  home.mount                                          loaded active mounted   /home
  sys-fs-fuse-connections.mount              loaded active mounted   FUSE Control File System
  sys-kernel-debug.mount                        loaded active mounted   Debug File System
  tmp.mount                                             loaded active mounted   /tmp
  var.mount                                               loaded active mounted   /var
  acpid.path                                              loaded active running   ACPI Events Check
  systemd-ask-password-console.path     loaded active waiting   Dispatch Password Requests to Console
  systemd-ask-password-wall.path           loaded active waiting   Forward Password Requests to Wall Dir
  init.scope                                               loaded active running   System and Service Manager
  acpid.service                                         loaded active running   ACPI event daemon
  avahi-daemon.service                           loaded active running   Avahi mDNS/DNS-SD Stack

systemctl start →  ativa um serviço 
systemctl stop →   desativa um serviço
systemctl restart →  reinicia um serviço
systemctl status →  mostra o estatus do serviço se esta ativado, desativado, …
systemctl enable →  premite que um serviço seja iniciado no próximo boot
systemctl desable →  desabilita o serviço para não iniciar no próximo boot
systemctl -t  →  este comando serve pra especificar uma unidade, que foram vistas anteriormente.
sidney@debian:~$ systemctl -t  swap
UNIT                                    LOAD   ACTIVE SUB    DESCRIPTION
dev-disk-by\x2duuid-4759db9b\x2d6797\x2d4854\x2d92fc\x2ddb265d7ae569.swap loaded active active /dev/

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

systemctl list-unit-files → este comando mostra uma lista de todos serviços unit e o estado, de modo geral.
sidney@debian:~$ systemctl list-unit-files
UNIT FILE                                                                 STATE    
proc-sys-fs-binfmt_misc.automount                        static   
-.mount                                                                   generated
dev-hugepages.mount                                            static   
dev-mqueue.mount                                                 static   
home.mount                                                            nerated
media-cdrom0.mount                                              generated
proc-sys-fs-binfmt_misc.mount                                static   
sys-fs-fuse-connections.mount                                static   
sys-kernel-config.mount                                          static   

systemctl –state=failed → este comando mostra os serviços que falharam, muito provavelmente por não estar configurado como no caso do bind9, 
sidney@debian:~$ systemctl --state=failed
  UNIT          LOAD   ACTIVE SUB    DESCRIPTION
● bind9.service loaded failed failed BIND Domain Name Server

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.


(referência do manual systemd)
class="fb-like" data-share="true" data-width="450" data-show-faces="true">