Systemd é um gerenciador de sistema e serviço para Linux, compatível com scripts de inicialização SysV e LSB. Systemd fornece recursos de paralelização agressiva, usa ativação de soquete e D-Bus para iniciar serviços, oferece início de daemons on-demand, acompanha processos usando clusters Linux, suporta instantâneo e restauração do estado do sistema, mantém pontos de montagem e automount e implementa um Lógica de controle de serviço baseada em dependência transacional elaborada. Pode funcionar como uma substituição drop-in para sysvinit. Para mais informações, assista o vídeo em youtubewatchvTyMLi8QF6sw Para administradores de sistema Os administradores do sistema podem visitar esta página. Para entender como usar as chamadas nativas do sistema que substituem o fluxo de trabalho antigo no SysVinit. Observe que o serviço e os comandos chkconfig continuarão a funcionar como esperado no mundo systemd. Por que a documentação sistema systemd systemd possui uma documentação muito abrangente. Consulte a Linha de Comando do Boot Kernel No boot systemd ativa (por padrão), a unidade de destino default. target cujo trabalho é ativar serviços e outras unidades puxando-os por dependências. Para substituir a unidade para ativar, o sistema exibe seus próprios argumentos da linha de comando do kernel através da opção de linha de comando systemd. unit. Isso pode ser usado para inicializar temporariamente em uma unidade de inicialização diferente. Os níveis de execução clássicos são substituídos como segue: systemd. unitrescue. target é uma unidade de destino especial para configurar o sistema base e um shell de resgate (semelhante ao nível de execução 1) systemd. unitemergency. target. É muito parecido com a passagem de initbinsh, mas com a opção de inicializar o sistema completo a partir daí systemd. unitmulti-user. target para configurar um sistema multiusuário não gráfico systemd. unitgraphical. target para configurar uma tela de login gráfico. Para obter detalhes sobre essas unidades especiais de inicialização systemd, veja a página man systemd. special. Scripts O que é a ferramenta para gerenciar serviços com systemd systemctl é a principal ferramenta a ser usada. Ele combina a funcionalidade do serviço e do chkconfig em uma única ferramenta que você pode usar, por exemplo, para serviços habilitáveis de forma permanente ou somente para a sessão atual. Liste todos os serviços em execução, etc.: consulte man systemctl para obter mais detalhes. Systemd-cgls lista o processo em execução em um formato de árvore. Pode mostrar recursivamente o conteúdo de qualquer grupo de controle. Consulte man systemd-cgls para obter mais detalhes. Como faço para iniciar ou serviços habilitáveis Ative um serviço imediatamente: Desativa um serviço imediatamente: reinicia um serviço: mostra o status de um serviço, seja ele executado ou não: permite que um serviço seja iniciado no boot: desativa um serviço para não iniciar durante Inicialização: impede que um serviço seja iniciado dinamicamente ou mesmo manualmente, a menos que desmascarado: verifique se um serviço já está habilitado ou não: consulte man systemctl para obter mais detalhes. Como faço para mudar o alvo (runlevel) systemd tem o conceito de metas, que é uma substituição mais flexível para runlevels no sysvinit. O nível de execução 3 é emulado pelo multiusuário. target. O nível de execução 5 é emulado por graphical. target. Runlevel3.target é um link simbólico para multiusuário. target e runlevel5.target é um link simbólico para graphical. target. Você pode alternar para o nível de execução 3 executando Você pode alternar para o nível de execução 5 executando Como eu mudo o alvo padrão. O gráfico é o padrão. Você pode querer multiusuário. target para o equivalente de não gráfico (runlevel 3) do init sysv. A lista completa de destinos pode ser acessada via systemctl list-units --typetarget systemd não usa o arquivo etcinittab. Como conhecer o destino atual Como desligar a máquina Algumas possibilidades são: halt - p. Init 0. shutdown - P agora Observe que a parada usou o mesmo que poweroff em versões anteriores do Fedora, mas systemd distingue entre os dois, então parar sem parâmetros agora faz exatamente o que diz - simplesmente pára o sistema sem desligá-lo. O comando de serviço funciona com o sistema sim. Foi modificado para chamar systemctl automaticamente ao lidar com arquivos de serviço systemd. Então, qualquer um dos seguintes comandos faz a mesma coisa. O comando chkconfig funciona com sistema. Sim, para ativar os serviços de saída, a compatibilidade foi fornecida de ambas as maneiras. Chkconfig foi modificado para chamar systemctl ao lidar com arquivos de serviço systemd. Também o systemctl chama automaticamente chkconfig ao lidar com um arquivo init tradicional do sysv. Então, qualquer um dos seguintes comandos faz o mesmo chkconfig --list não lista os serviços SystemD, apenas os serviços Sys V. A saída do chkconfig toma nota disso, juntamente com o fornecimento de informações adicionais. Os serviços de configuração de sistema funcionam com o sistema. Como eu altero o número de gettys executando por padrão. A maneira mais simples é editar etcsystemdlogind. conf (página man): Esta configuração entrará em vigor após a reinicialização. Alternativamente, os servidores getty. s que abrem o prompt de login podem ser ativados e iniciados individualmente. Para adicionar outro getty: Para remover um getty: systemd não usa o arquivo etcinittab. Como faço para configurar o login automático em um terminal de console virtual Primeiro crie um novo serviço semelhante ao getty. service: então edite os valores ExecStart, Restart e Alias, como este: e finalmente recarregue o daemon e inicie o serviço: Observe que se você sair da sessão tty8 , Você não poderá usá-lo até a próxima reinicialização ou iniciar manualmente pelo systemctl, exceto se você deixar Reiniciar como sempre, mas eu recomendo evitar isso de acordo com os motivos de segurança. Como faço para personalizar um arquivo de unidade, adicione um arquivo de unidade personalizado. A melhor maneira de personalizar arquivos de unidades é adicionar etcsystemdsystemfoobar. service. d.conf onde foobar. service é o nome do serviço que deseja personalizar. Se um diretório já existe, crie um e solte um arquivo conf com as configurações que deseja substituir. Por exemplo, consulte man systemd. unit page para obter mais detalhes. Não se esqueça de recarregar o daemon do sistema usando systemctl daemon-reload e systemctl reiniciar foobar depois de editar um arquivo da unidade em que foobar é o nome da unidade. Observe também que você pode systemd-delta listar os arquivos da unidade que foram personalizados e também as diferenças precisas. Especial cuidado deve ser tomado ao substituir as opções que podem ser definidas em tempos múltiplos (ExecStart. ExecStartPre. ExecStartPost são um exemplo comum). Atribuir algum valor para a opção anexa à lista existente, enquanto asserindo o valor vazio redefine a lista. Por exemplo, digamos que temos um arquivo de serviço como este: Quando iniciado, este serviço será impresso. As mesmas regras se aplicam aos trechos nos diretórios. d. Isso significa que fragmentos que substituem ExecStart e configurações semelhantes, geralmente devem começar com a atribuição vazia ExecStart. Seguido pela nova configuração. Como faço para depurar problemas systemd systemd vem com extensa documentação incluindo várias páginas man. Referencessystemd é um conjunto de blocos de construção básicos para um sistema Linux. Ele fornece um gerenciador de sistema e serviço que é executado como PID 1 e inicia o resto do sistema. Systemd fornece recursos de paralelização agressiva, usa ativação de soquete e D-Bus para serviços iniciais, oferece início de daemons sob demanda, acompanha os processos usando grupos de controle do Linux. Mantém pontos de montagem e automount e implementa uma elaborada lógica de controle de serviço baseada em dependências transacionais. Systemd suporta scripts de inicialização SysV e LSB e funciona como um substituto para sysvinit. Outras partes incluem um daemon de log, utilitários para controlar a configuração básica do sistema, como o nome do host, data, localidade, manter uma lista de usuários conectados e usar contêineres e máquinas virtuais, contas de sistema, diretórios e configurações de tempo de execução e daemons para gerenciar rede simples Configuração, sincronização de tempo da rede, reencaminhamento de log e resolução de nomes. Nota: Para uma explicação detalhada sobre por que o Arch mudou para SystemD. Veja o post do fórum. Uso básico do sistema O comando principal usado para introspecção e controle systemd é systemctl. Alguns dos seus usos estão examinando o estado do sistema e gerenciando o sistema e os serviços. Veja man systemctl para obter mais detalhes. Dica: você pode usar todos os seguintes comandos systemctl com a opção de host do usuário - H para controlar uma instância systemd em uma máquina remota. Isso usará SSH para se conectar à instância systemd remota. Systemadm é o frontend gráfico oficial para systemctl e é fornecido pelo pacote systemd-ui. Os usuários de plasma podem instalar o systemd-kcm como uma interface gráfica para systemctl. Após a instalação, o módulo será adicionado na administração do sistema. Analisando o estado do sistema Mostra o status do sistema usando: Lista de unidades em execução: lista de unidades com falha: os arquivos de unidade disponíveis podem ser vistos no sistema usrlibsystemds e sistemas de sistema (o último tem precedência). Lista de arquivos de unidade instalados com: Usando unidades As unidades podem ser, por exemplo, serviços (.service), pontos de montagem (.mount), dispositivos (.device) ou soquetes (.socket). Ao usar systemctl. Você geralmente precisa especificar o nome completo do arquivo da unidade, incluindo seu sufixo, por exemplo sshd. socket. No entanto, existem algumas formas curtas ao especificar a unidade nos seguintes comandos systemctl: se você não especificar o sufixo, o sistema irá assumir. service. Por exemplo, netctl e netctl. service são equivalentes. Os pontos de montagem serão automaticamente traduzidos para a unidade. mount apropriada. Por exemplo, especificar a casa é equivalente a home. mount. Semelhante aos pontos de montagem, os dispositivos são automaticamente traduzidos para a unidade apropriada. device, portanto, especificar devsda2 é equivalente a dev-sda2.device. Veja man systemd. unity para obter detalhes. Nota: Alguns nomes de unidades contêm um sinal (por exemplo, seqüência de caracteres. service): isso significa que eles são instâncias de uma unidade de modelo, cujo nome de arquivo real não contém a parte de string (por exemplo, name. service). String é chamado de identificador de instância. E é semelhante a um argumento que é passado para a unidade de modelo quando chamado com o comando systemctl: no arquivo da unidade, ele substituirá o especificador i. Para ser mais preciso, antes de tentar instanciar a unidade de modelo name. suffix, o systemd procurará uma unidade com o nome exato do nome do arquivo namestring. suffix, embora, por convenção, esse choque ocorra raramente, ou seja, a maioria dos arquivos de unidade que contém um sinal significam Para serem modelos. Além disso, se uma unidade de modelo for chamada sem um identificador de instância, ela apenas falhará, já que o especificador i não pode ser substituído. Dica: A maioria dos comandos a seguir também funcionam se várias unidades forem especificadas, veja man systemctl para obter mais informações. O interruptor --now pode ser usado em conjunto com enable. Desativar. E máscara para iniciar, parar ou mascarar imediatamente a unidade em vez de depois da próxima inicialização. Um pacote pode oferecer unidades para diferentes fins. Se você acabou de instalar um pacote, Pacman - Qql pacote grep - Fe. service - e. socket pode ser usado para verificar e encontrá-los. Inicie uma unidade imediatamente: pare uma unidade imediatamente: peça a uma unidade para recarregar sua configuração: mostre o status de uma unidade, incluindo se ela está sendo executada ou não: Verifique se uma unidade já está habilitada ou não: Ative uma unidade a ser iniciada Inicialização. Desative uma unidade para não iniciar durante a inicialização: Masque uma unidade para impossibilitar a inicialização: mostre a página de manual associada a uma unidade (isso deve ser suportado pelo arquivo da unidade): Recarregar o sistema. Digitando unidades novas ou alteradas. O gerenciamento de energia polkit é necessário para o gerenciamento de energia como um usuário não privilegiado. Se você estiver em uma sessão de usuário systemd-logind local e nenhuma outra sessão estiver ativa, os seguintes comandos funcionarão sem privilégios de root. Caso contrário (por exemplo, porque outro usuário está logado em um tty), systemd solicitará automaticamente a senha do root. Desligue e reinicie o sistema: desligue e desligue o sistema: Suspenda o sistema: Coloque o sistema em hibernação: coloque o sistema em estado de suspensão híbrida (ou suspenda para ambos): Escrevendo arquivos de unidade A sintaxe do sistema Os arquivos da unidade s são inspirados nos arquivos. desktop da Especificação de Entrada do Desktop XDG, que, por sua vez, são inspirados pelos arquivos. ini do Microsoft Windows. Os arquivos da unidade são carregados de dois locais. Do precedente mais baixo ao mais alto são: usrlibsystemdsystem. Unidades fornecidas pelos sistemas instalados, etc. systemdsystem. Unidades instaladas pelo administrador do sistema Nota: Os caminhos de carga são completamente diferentes ao executar o sistema no modo de usuário. Os nomes das unidades Systemd só podem conter caracteres alfanuméricos ASCII, sublinhados e períodos. Todos os outros caracteres devem ser substituídos por escapes x2d em estilo C. Veja man systemd. unity e man systemd-escape para mais informações. Consulte as unidades instaladas pelos seus pacotes para obter exemplos, bem como a seção de exemplo anotado do man systemd. service. Dica: Os comentários que já foram adicionados podem também ser usados em arquivos de unidades, mas somente em novas linhas. Não use comentários de linha final após os parâmetros do sistema ou a unidade não ativará. Gerenciando dependências com systemd. As dependências podem ser resolvidas criando os arquivos da unidade corretamente. O caso mais típico é que a unidade A exige que a unidade B seja executada antes que A seja iniciada. Nesse caso, adicione Requer B e Após B para a seção Unidade de A. Se a dependência for opcional, adicione Wants B e After B em vez disso. Observe que Wants e Requires não implicam After. O que significa que se After não for especificado, as duas unidades serão iniciadas em paralelo. As dependências geralmente são colocadas em serviços e não em metas. Por exemplo, o network. target é puxado por qualquer serviço configurando suas interfaces de rede, portanto, solicitando sua unidade personalizada depois de ser suficiente, pois o network. target foi iniciado de qualquer maneira. Tipos de serviço Existem vários tipos de start-up diferentes a serem considerados ao escrever um arquivo de serviço personalizado. Isso é definido com o parâmetro Type na seção Serviço: Tiposimples (padrão): systemd considera que o serviço será iniciado imediatamente. O processo não deve ser o garfo. Não use esse tipo se outros serviços precisam ser solicitados neste serviço, a menos que seja ativado por soquete. Identificação de tipo. Systemd considera o serviço iniciado assim que o processo forks e o pai saiu. Para os daemons clássicos, use esse tipo, a menos que você saiba que não é necessário. Você também deve especificar o PIDFile, de modo que systemd possa acompanhar o processo principal. Typeoneshot. Isso é útil para scripts que fazem um único trabalho e depois saem. Você pode querer configurar RemainAfterExityes também para que systemd ainda considere o serviço como ativo após o processo ter saído. Typenotify. Idêntico a Typimple. Mas com a estipulação de que o daemon enviará um sinal ao systemd quando estiver pronto. A implementação de referência para esta notificação é fornecida por libsystemd-daemon. so. Typedbus. O serviço é considerado pronto quando o BusName especificado aparece no barramento do sistema DBuss. Typeidle. Systemd atrasará a execução do binário do serviço até que todos os trabalhos sejam despachados. Além desse comportamento é muito parecido com o Tipompleto. Veja a página man systemd. service (5) para obter uma explicação mais detalhada sobre os valores de Tipo. Edição de unidades fornecidas Para evitar conflitos com o pacman, os arquivos de unidade fornecidos pelos pacotes não devem ser editados diretamente. Existem duas maneiras seguras de modificar uma unidade sem tocar no arquivo original: crie um novo arquivo de unidade que substitua a unidade original ou crie snippets de entrada que são aplicados em cima da unidade original. Para ambos os métodos, você deve recarregar a unidade posteriormente para aplicar suas alterações. Isso pode ser feito editando a unidade com a edição systemctl (que recarrega a unidade automaticamente) ou recarregando todas as unidades com: Dica: Você pode usar systemd-delta para ver quais arquivos da unidade foram substituídos ou estendidos e o que exatamente foi alterado . Use systemctl cat unit para ver o conteúdo de um arquivo de unidade e todos os trechos de drop-in associados. O destaque de sintaxe para arquivos de unidades Systemd no Vim pode ser ativado instalando vim-systemd. Arquivos da unidade de substituição Para substituir o arquivo de unidade usrlibsystemdsystem unit. Crie a unidade de sistema de arquivos etc e reenele a unidade para atualizar os links simbólicos: Isso abre a unidade do sistema de sistema em seu editor (copiando a versão instalada se ainda não existe) e recarrega-a automaticamente quando você terminar de editar. Nota: O Pacman não atualiza os arquivos da unidade de substituição quando os originais são atualizados, portanto este método pode dificultar a manutenção do sistema. Por este motivo, a próxima abordagem é recomendada. Arquivos drop-in Para criar arquivos drop-in para a unidade usrlibsystemdsystem da unidade. Crie o diretório etcsystemdsystem unit. d e coloque arquivos. conf lá para substituir ou adicionar novas opções. Systemd irá analisar esses arquivos. conf e aplicá-los em cima da unidade original. A maneira mais fácil de fazer isso é executar: Isso abre a unidade do sistema do arquivo etc. doverride. conf no seu editor de texto (criando-o, se necessário) e recarrega automaticamente a unidade quando você terminar de editar. Reverter para a versão do fornecedor Para reverter as alterações feitas em uma unidade feita usando o sistema systemctl, faça o seguinte: Por exemplo, se você quiser simplesmente adicionar uma dependência adicional a uma unidade, você pode criar o seguinte arquivo: Como outro exemplo, para substituir o ExecStart Diretiva para uma unidade que não é do tipo oneshot. Crie o seguinte arquivo: Observe como o ExecStart deve ser desmarcado antes de ser reatribuído 1. O mesmo é válido para cada item que pode ser especificado várias vezes, e. OnCalendar para temporizadores. Mais um exemplo para reiniciar automaticamente um serviço: Razão: descrição não clara, conteúdo colado em cópia (menciona explicitamente o Fedora). (Discutir em conversa: seção SystemdMake Alveja mais claramente) systemd usa alvos que atendem a um propósito similar como runlevels, mas atuam um pouco diferentes. Cada alvo é nomeado em vez de numerado e destina-se a servir um propósito específico com a possibilidade de ativar múltiplos ativos ao mesmo tempo. Alguns objetivos s são implementados pela herança de todos os serviços de outro alvo e adicionando serviços adicionais a ele. Há o alvo s sistematicamente que imita os níveis de execução comuns do SystemVinit, de modo que você ainda pode mudar o alvo usando o comando familiar de telinit RUNLEVEL. Obtenha alvos atuais O seguinte deve ser usado em systemd em vez de executar runlevel. Criar alvo personalizado Os níveis de execução que possuíam um significado definido em sysvinit (ou seja, 0, 1, 3, 5 e 6) possuem um mapeamento 1: 1 com um alvo systemd específico. Infelizmente, não existe uma boa maneira de fazer o mesmo para os níveis de execução definidos pelo usuário como 2 e 4. Se você fizer uso disso, sugere-se que você crie um novo alvo SystemD nomeado como sistema de sistema de seu destino que leve um dos níveis de execução existentes Como base (você pode ver usrlibsystemdsystemgraphical. target como um exemplo), faça um diretório etcsystemdsystem seu alvo. E depois simbolize os serviços adicionais do usrlibsystemdsystem que você deseja habilitar. Tabela de metas Alterar o destino atual Nos destinos de sistema são expostos através de unidades de destino. Você pode alterá-los assim: isso só alterará o alvo atual e não afetará a próxima inicialização. Isto é equivalente a comandos como telinit 3 ou telinit 5 no Sysvinit. Alterar o destino padrão para inicializar O alvo padrão é default. target. Que é alias por padrão para graphical. target (que corresponde aproximadamente ao antigo runlevel 5). Para alterar o destino padrão no momento da inicialização, adicione um dos seguintes parâmetros do kernel ao seu gerenciador de inicialização: systemd. unitmulti-user. target (que corresponde aproximadamente ao antigo nível de execução 3), systemd. unitrescue. target (que corresponde aproximadamente ao Antigo runlevel 1). Alternativamente, você pode deixar o carregador de inicialização sozinho e alterar default. target. Isso pode ser feito usando systemctl. Para poder substituir o padrão predeterminado set. target. Use a opção de força: o efeito deste comando é emitido por systemctl, um link simbólico para o novo alvo padrão é feito em etcsystemdsystemdefault. target. Arquivos temporários systemd-tmpfiles cria, exclui e limpa arquivos e diretórios voláteis e temporários. Ele lê os arquivos de configuração em etctmpfiles. d e usrlibtmpfiles. d para descobrir quais ações executar. Os arquivos de configuração no diretório anterior têm precedência sobre aqueles no último diretório. Os arquivos de configuração geralmente são fornecidos juntamente com arquivos de serviço, e eles são nomeados no estilo de usrlibtmpfiles. d programa. conf. Por exemplo, o daemon do Samba espera que o diretório runsamba exista e tenha as permissões corretas. Portanto, o pacote samba é fornecido com esta configuração: os arquivos de configuração também podem ser usados para escrever valores em determinados arquivos no arranque. Por exemplo, se você usou etcrc. local para desativar a ativação de dispositivos USB com echo USBE gt procacpiwakeup. Você pode usar o seguinte arquivo tmp em vez disso: veja as páginas manuais systemd-tmpfiles (8) e tmpfiles. d (5) para obter detalhes. Nota: Este método pode não funcionar para definir opções no sistema, pois o serviço systemd-tmpfiles-setup pode ser executado antes que os módulos apropriados do dispositivo sejam carregados. Nesse caso, você pode verificar se o módulo tem um parâmetro para a opção que deseja configurar com o módulo modinfo e definir esta opção com um arquivo de configuração em etcmodprobe. d. Caso contrário, você terá que escrever uma regra udev para definir o atributo apropriado assim que o dispositivo aparecer. Um temporizador é um arquivo de configuração de unidade cujo nome termina com. timer e codifica informações sobre um temporizador controlado e supervisionado pelo systemd. Para ativação baseada em timer. Veja systemdTimers. Uma vez que systemd é um substituto para o System Init, ele é responsável pelas montagens especificadas em etcfstab. Na verdade, ele vai além das capacidades usuais do fstab, implementando opções especiais de montagem prefixadas com x-systemd. Veja FstabAutomount com systemd para um exemplo de automação (montagem on-demand) usando essas extensões. Consulte 2 para obter a documentação completa dessas extensões. Systemd tem seu próprio sistema de registro chamado jornal, portanto, executar um daemon syslog não é mais necessário. Para ler o log, use: No Arch Linux, o diretório varlogjournal é parte do pacote systemd e o diário (quando o Armazenamento está configurado para auto no etcsystemdjournald. conf) será gravado no varlogjournal. Se você ou algum programa excluir esse diretório, o sistema não o recriará automaticamente e, em vez disso, redigirá seus logs em runsystemdjournal de forma não persistente. No entanto, a pasta será recriada quando você configura Storagepersistent e execute o systemctl reiniciar systemd-journald (ou reiniciar). O diário Systemd classifica mensagens por nível de prioridade e facilidade. A classificação de registro corresponde ao protocolo Syslog clássico (RFC 5424). Nível de prioridade Um código de gravidade do syslog (no sistema chamado prioridade) é usado para marcar a importância de uma mensagem RFC 5424 Seção 6.2.1. Então, facilidades úteis para assistir: 0,1,3,4,9,10,15. Filtrar o journalctl de saída permite filtrar a saída por campos específicos. Esteja ciente de que, se houver muitas mensagens a serem exibidas ou a filtragem de grandes prazos, a saída desse comando pode ser adiada por algum tempo. Dica: enquanto o diário é armazenado em formato binário, o conteúdo das mensagens armazenadas não é modificado. Isso significa que é visível com strings. Por exemplo, para recuperação em um ambiente que não tenha instalado sistema. Exemplo de comando: mostra todas as mensagens desta inicialização: no entanto, muitas vezes um está interessado em mensagens não da atual, mas da inicialização anterior (por exemplo, se uma falha do sistema irrecuperável aconteceu). Isso é possível através do parâmetro de deslocamento opcional do sinalizador - b: journalctl - b -0 mostra as mensagens da inicialização atual, journalctl - b -1 da inicialização anterior, journalctl - b -2 do segundo anterior e assim por diante. Veja man 1 journalctl para descrição completa, a semântica é muito mais poderosa. Mostrar todas as mensagens a partir da data (e do tempo opcional): Mostrar todas as mensagens desde 20 minutos atrás: Siga as novas mensagens: Mostra todas as mensagens por um executável específico: Mostra todas as mensagens por um processo específico: mostra todas as mensagens por uma unidade específica: mostra o anel do kernel Buffer: Mostrar apenas mensagens de prioridade de erro, críticas e alertas Os números também podem ser usados, journalctl - p 3..1. Se uma única palavra numérica usada, journalctl - p 3 - todos os níveis de prioridade mais alta também incluíram. Mostrar equivalente auth. log, filtrando no recurso syslog: veja man 1 journalctl. Man 7 systemd. journal-fields. Ou publicação do blog Lennarts para detalhes. Dica: Por padrão, journalctl trunca linhas mais longas do que a largura da tela, mas em alguns casos, pode ser melhor habilitar o encapsulamento em vez de truncar. Isso pode ser controlado pela variável de ambiente SYSTEMDLESS. Que contém opções passadas para menos (o pager padrão) e padrão para FRSXMK (veja o homem 1 menos e man 1 journalctl para detalhes). Ao omitir a opção S, a saída será enrolada em vez de truncada. Por exemplo, inicie o journalctl da seguinte maneira: Se você quiser configurar esse comportamento como padrão, exporte a variável do limite de tamanho do diário Se o diário for persistente (não volátil), seu limite de tamanho é definido como um valor padrão de 10 Tamanho do sistema de arquivos subjacente, mas limitado a 4 GiB. Por exemplo, com varlogjournal localizado em uma partição de 20 GiB, os dados do diário podem demorar até 2 GiB. Em uma partição de 50 GiB, seria máximo de 4 GiB. O tamanho máximo do periódico persistente pode ser controlado por descomentar e alterar o seguinte: também é possível usar o mecanismo de substituição da configuração do snippet drop-in em vez de editar o arquivo de configuração global. Nesse caso, não se esqueça de colocar as substituições sob o cabeçalho do Diário: veja man journald. conf para mais informações. Limpe os arquivos de diário manualmente Os arquivos de diários podem ser removidos globalmente de varlogjournal usando, por exemplo, Rm. Ou podem ser cortadas de acordo com vários critérios usando journalctl. Exemplos: remova arquivos de diário arquivados até o espaço em disco que eles usam cai abaixo de 100M: faça com que todos os arquivos de diário não contenham dados com mais de 2 semanas. Veja man journalctl para mais informações. O Journald em conjunto com o syslog A compatibilidade com uma implementação clássica, syslog syslog não-journald pode ser fornecida deixando systemd encaminhar todas as mensagens através do socket runsystemdjournalsyslog. Para fazer o daemon do syslog funcionar com o diário, ele tem que se ligar a esse soquete em vez de devlog (anúncio oficial). O padrão journald. conf para encaminhamento para o soquete é ForwardToSyslogno para evitar despesas gerais do sistema, porque rsyslog ou syslog-ng puxam as mensagens da revista por si só. Encaminhe o journald para devtty12 Crie um diretório drop-in etcsystemdjournald. conf. d e crie um arquivo fw-tty12.conf nele: especifique um diário diferente para exibição. Pode ser necessário verificar os registros de outro sistema que está morto no Água, como arrancar de um sistema ao vivo para recuperar um sistema de produção. Nesse caso, pode-se montar o disco, e. Mnt. E especifique o caminho do diário via - D - diretório. Assim: Dicas e truques Habilite as unidades instaladas por padrão Motivo: como funciona com unidades instanciadas (Discutir em Talk: Systemd) O Arch Linux é fornecido com usrlibsystemdsystem-preset99-default. preset contendo desativação. Isso faz com que a predefinição Systemctl desative todas as unidades por padrão, de modo que, quando uma nova embalagem estiver instalada, o usuário deve habilitar a unidade manualmente. Se esse comportamento não for desejado, basta criar um link simbólico de etcsystemdsystem-preset99-default. preset para devnull para substituir o arquivo de configuração. Isso fará com que o preset systemctl habilite todas as unidades que se instalam independentemente do tipo de unidade que não seja especificado em outro arquivo em um diretório de configuração do systemctl. As unidades de usuário não são afetadas. Consulte a página de manual para systemd. preset para obter mais informações. Nota: habilitar todas as unidades por padrão pode causar problemas com pacotes que contenham duas ou mais unidades mutuamente exclusivas. Systemctl preset foi projetado para ser usado por distribuições e rotas ou administradores de sistema. No caso em que duas unidades conflitantes estariam habilitadas, você deve especificar explicitamente qual deve ser desabilitado em um arquivo de configuração predefinido conforme especificado na página de manual para systemd. preset. Ambientes de aplicativos Sandboxing Um arquivo de unidade pode ser criado como uma caixa de areia para isolar aplicativos e seus processos em um ambiente virtual endurecido. Systemd alavanca namespaces. White-blacklisting of Capabilities. E grupos de controle para processos de contêiner através de uma configuração de ambiente de execução extensa. O aprimoramento de um arquivo de unidade systemd existente com sandboxing de aplicativo normalmente requer testes de teste e erro acompanhados pelo uso generoso de strace. Stderr e journalctl erro logging e instalações de saída. Você pode querer primeiro procurar documentação a montante para testes já realizados para basear ensaios em. Alguns exemplos de como o sandboxing com systemd pode ser implantado: CapabilityBoundingSet define um conjunto de capacidades permitidas na lista branca, mas também pode ser usado para listar uma capacidade específica para uma unidade. A capacidade CAPSYSADM, por exemplo, que deve ser um dos objetivos de um sandbox seguro. CapabilityBoundingSet CAPSYSADM UnboundSandboxing mostra um exemplo completo de recursos systemd para sandboxing. Solução de problemas Pesquisando erros do sistema Como um exemplo, investigaremos um erro com o serviço systemd-modules-load: 1. Vamos encontrar os serviços systemd que não iniciaram: 2. Ok, encontramos um problema com o serviço systemd-modules-load. Queremos saber mais: se o ID do Processo não estiver listado, basta reiniciar o serviço falhado com systemctl reiniciar systemd-modules-load 3. Agora, temos o ID do processo (PID) para investigar este erro em profundidade. Digite o seguinte comando com o ID do Processo atual (aqui: 15630): 4. Vemos que algumas das configurações do módulo do kernel têm configurações erradas. Portanto, damos uma olhada nessas configurações em etcmodules-load. d. 5. A mensagem de erro Falha ao encontrar a lista negra do módulo usblp pode estar relacionada a uma configuração errada dentro de blacklist. conf. Permite desativá-lo com a inserção de uma fuga antes de cada opção que encontramos através do passo 3: 6. Agora, tente iniciar o sistema-módulos-carga. Se foi bem sucedido, isso não deve induzir nada. Se você vir algum erro, volte para a etapa 3 e use o novo PID para resolver os erros restantes. Se tudo estiver bem, você pode verificar se o serviço foi iniciado com sucesso: Muitas vezes você pode resolver esse tipo de problemas como mostrado acima. Para uma investigação mais aprofundada, consulte Diagnóstico de problemas de inicialização. Diagnosticando problemas de inicialização systemd tem várias opções para diagnosticar problemas com o processo de inicialização. Consulte a depuração de inicialização e a documentação de depuração do sistema. Diagnosticando problemas com um serviço específico Motivo: Isso pode não capturar todos os erros, como bibliotecas em falta. (Discutir em conversa do usuário: AlucrydPlex) Se algum serviço sistemaado se comportar mal e você deseja obter mais informações sobre o que está acontecendo, defina a variável de ambiente SYSTEMDLOGLEVEL para depurar. Por exemplo, para executar o daemon systemd-networkd no modo de depuração: Ou, de forma equivalente, modifique o arquivo de serviço temporariamente para obter uma saída suficiente. Por exemplo: se as informações de depuração forem necessárias a longo prazo, adicione a variável de maneira regular. Shutdownreboot leva muito longo Se o processo de desligamento demorar muito (ou parece congelar) é provável que um serviço que não saia seja culpado. Systemd espera algum tempo para cada serviço sair antes de tentar matá-lo. To find out if you are affected, see this article. Short lived processes do not seem to log any output If journalctl - u foounit does not show any output for a short lived service, look at the PID instead. For example, if systemd-modules-load. service fails, and systemctl status systemd-modules-load shows that it ran as PID 123, then you might be able to see output in the journal for that PID, i. e. journalctl - b PID61123. Metadata fields for the journal such as SYSTEMDUNIT and COMM are collected asynchronously and rely on the proc directory for the process existing. Fixing this requires fixing the kernel to provide this data via a socket connection, similar to SCMCREDENTIALS. Boot time increasing over time After using systemd-analyze a number of users have noticed that their boot time has increased significantly in comparison with what it used to be. After using systemd-analyze blame NetworkManager is being reported as taking an unusually large amount of time to start. The problem for some users has been due to varlogjournal becoming too large. This may have other impacts on performance, such as for systemctl status or journalctl. As such the solution is to remove every file within the folder (ideally making a backup of it somewhere, at least temporarily) and then setting a journal file size limit as described in Journal size limit. systemd-tmpfiles-setup. service fails to start at boot Starting with systemd 219, usrlibtmpfiles. dsystemd. conf specifies ACL attributes for directories under varlogjournal and, therefore, requires ACL support to be enabled for the filesystem the journal resides on. See Access Control ListsEnabling ACL for instructions on how to enable ACL on the filesystem that houses varlogjournal. systemctl enable fails for symlinks in etcsystemdsystem If etcsystemdsystem foo. service is a symlink and systemctl enable foo. service is run, it will fail with this error: This is a design choice of systemd. As a workaround, enabling by absolute path works: dependent services are not started when starting a service manually One (in)famous example is libvirtd. service which needs the virtlogd. socket to function properly. The dependencies in usrlibsystemdsystemlibvirtd. service are defined as This only defines the necessarydependent sockets to be enabled services(i. e. as autostart), too - but does not start them whenever the DISABLED ( non-autostarting) service ist started manually e. g. by running systemctl start libvirtd Thus the correct () way to manually start a service with dependent subservices once (instead of at each start of the system) probably is systemd version printed on boot is not the same as installed package version You need to regenerate your initramfs and the versions should match. Tip: A pacman hook can be used to automatically regenerate the initramfs every time systemd is upgraded. See this forum thread and PacmanHooks. Binary Options Trading with IQ Option What is binary options First of all, it is a highly profitable online trading tool that allows you to estimate the amount of potential profit in advance. Negociação de opções binárias pode trazer uma renda substancial no menor tempo possível. Traders compra opções a um preço predeterminado. Negociação on-line pode ser rentável se o comerciante identifica corretamente o movimento do mercado. Vantagens de negociação de opções binárias é uma área de alto risco onde você pode dobrar ou até mesmo triplicar seu capital ou perdê-lo em poucos minutos. Opções binárias têm várias vantagens que tornam possível obter mais lucro com risco previsível. Uma opção com um lucro fixo difere da negociação convencional. Iniciantes podem trocar opções binárias com IQ Option tão bem como comerciantes experientes. Todo o processo é totalmente automatizado. Os comerciantes das opções binárias estão cientes de seus lucros adiantado seu objetivo principal é selecionar a direção correta do movimento do mercado. Eles precisam escolher entre duas direções apenas para cima ou para baixo. Dois tipos de comércio on-line A plataforma IQ Option permite que você troque opções binárias em dois modos básicos. A conta da prática é para o treinamento. Para abrir uma conta prática e para testar sua força, você nem precisa fazer um depósito. Para negociação real, você precisa depositar 10 apenas. Isso garante um bônus de até 36. Ao abrir uma conta para um montante maior (de 3.000), um gerente de conta pessoal estará ao seu serviço. As operações de negociação oferecidas neste website podem ser consideradas Operações de Negociação de Alto Risco ea sua execução pode ser muito arriscada. Comprar instrumentos financeiros ou utilizar serviços oferecidos no site pode resultar em perdas significativas ou mesmo em uma perda total de todos os fundos em sua conta. É-lhe concedido direitos não-exclusivos não-transferíveis limitados para utilizar o IP fornecido neste website para fins pessoais e não comerciais em relação aos serviços oferecidos no Website apenas. A empresa atua fora da Federação Russa. Eu. iqoption é de propriedade e operado pela Iqoption Europe Ltd. IQ Option, 20132017 Informações de recuperação de senha foram enviadas com sucesso para o seu e-mail O registro não está disponível na Federação Russa. If you think youre seeing this message by mistake, please contact supportiqoption. We hope you find this tutorial helpful. In addition to guides like this one, we provide simple cloud infrastructure for developers. Learn more rarr How To Use Journalctl to View and Manipulate Systemd Logs Introduction Some of the most compelling advantages of systemd are those involved with process and system logging. When using other tools, logs are usually dispersed throughout the system, handled by different daemons and processes, and can be fairly difficult to interpret when they span multiple applications. Systemd attempts to address these issues by providing a centralized management solution for logging all kernel and userland processes. The system that collects and manages these logs is known as the journal. The journal is implemented with the journald daemon, which handles all of the messages produced by the kernel, initrd, services, etc. In this guide, we will discuss how to use the journalctl utility, which can be used to access and manipulate the data held within the journal. General Idea One of the impetuses behind the systemd journal is to centralize the management of logs regardless of where the messages are originating. Since much of the boot process and service management is handled by the systemd process, it makes sense to standardize the way that logs are collected and accessed. The journald daemon collects data from all available sources and stores them in a binary format for easy and dynamic manipulation. This gives us a number of significant advantages. By interacting with the data using a single utility, administrators are able to dynamically display log data according to their needs. This can be as simple as viewing the boot data from three boots ago, or combining the log entries sequentially from two related services to debug a communication issue. Storing the log data in a binary format also means that the data can be displayed in arbitrary output formats depending on what you need at the moment. For instance, for daily log management you may be used to viewing the logs in the standard syslog format, but if you decide to graph service interruptions later on, you can output each entry as a JSON object to make it consumable to your graphing service. Since the data is not written to disk in plain text, no conversion is needed when you need a different on-demand format. The systemd journal can either be used with an existing syslog implementation, or it can replace the syslog functionality, depending on your needs. While the systemd journal will cover most administrators logging needs, it can also complement existing logging mechanisms. For instance, you may have a centralized syslog server that you use to compile data from multiple servers, but you also may wish to interleave the logs from multiple services on a single system with the systemd journal. You can do both of these by combining these technologies. Setting the System Time One of the benefits of using a binary journal for logging is the ability to view log records in UTC or local time at will. By default, systemd will display results in local time. Because of this, before we get started with the journal, we will make sure the timezone is set up correctly. The systemd suite actually comes with a tool called timedatectl that can help with this. First, see what timezones are available with the list-timezones option: This will list the timezones available on your system. When you find the one that matches the location of your server, you can set it by using the set-timezone option: To ensure that your machine is using the correct time now, use the timedatectl command alone, or with the status option. The display will be the same: The first line should display the correct time. Basic Log Viewing To see the logs that the journald daemon has collected, use the journalctl command. When used alone, every journal entry that is in the system will be displayed within a pager (usually less ) for you to browse. The oldest entries will be up top: You will likely have pages and pages of data to scroll through, which can be tens or hundreds of thousands of lines long if systemd has been on your system for a long while. This demonstrates how much data is available in the journal database. The format will be familiar to those who are used to standard syslog logging. However, this actually collects data from more sources than traditional syslog implementations are capable of. It includes logs from the early boot process, the kernel, the initrd, and application standard error and out. These are all available in the journal. You may notice that all of the timestamps being displayed are local time. This is available for every log entry now that we have our local time set correctly on our system. All of the logs are displayed using this new information. If you want to display the timestamps in UTC, you can use the --utc flag: Journal Filtering by Time While having access to such a large collection of data is definitely useful, such a large amount of information can be difficult or impossible to inspect and process mentally. Because of this, one of the most important features of journalctl is its filtering options. Displaying Logs from the Current Boot The most basic of these which you might use daily, is the - b flag. This will show you all of the journal entries that have been collected since the most recent reboot. This will help you identify and manage information that is pertinent to your current environment. In cases where you arent using this feature and are displaying more than one day of boots, you will see that journalctl has inserted a line that looks like this whenever the system went down: This can be used to help you logically separate the information into boot sessions. Past Boots While you will commonly want to display the information from the current boot, there are certainly times when past boots would be helpful as well. The journal can save information from many previous boots, so journalctl can be made to display information easily. Some distributions enable saving previous boot information by default, while others disable this feature. To enable persistent boot information, you can either create the directory to store the journal by typing: Or you can edit the journal configuration file: Under the Journal section, set the Storage option to persistent to enable persistent logging: When saving previous boots is enabled on your server, journalctl provides some commands to help you work with boots as a unit of division. To see the boots that journald knows about, use the --list-boots option with journalctl : This will display a line for each boot. The first column is the offset for the boot that can be used to easily reference the boot with journalctl. If you need an absolute reference, the boot ID is in the second column. You can tell the time that the boot session refers to with the two time specifications listed towards the end. To display information from these boots, you can use information from either the first or second column. For instance, to see the journal from the previous boot, use the -1 relative pointer with the - b flag: You can also use the boot ID to call back the data from a boot: Time Windows While seeing log entries by boot is incredibly useful, often you may wish to request windows of time that do not align well with system boots. This may be especially true when dealing with long-running servers with significant uptime. You can filter by arbitrary time limits using the --since and --until options, which restrict the entries displayed to those after or before the given time, respectively. The time values can come in a variety of formats. For absolute time values, you should use the following format: For instance, we can see all of the entries since January 10th, 2015 at 5:15 PM by typing: If components of the above format are left off, some defaults will be applied. For instance, if the date is omitted, the current date will be assumed. If the time component is missing, 00:00:00 (midnight) will be substituted. The seconds field can be left off as well to default to 00: The journal also understands some relative values and named shortcuts. For instance, you can use the words yesterday, today, tomorrow, or now. You do relative times by prepending - or to a numbered value or using words like ago in a sentence construction. To get the data from yesterday, you could type: If you received reports of a service interruption starting at 9:00 AM and continuing until an hour ago, you could type: As you can see, its relatively easy to define flexible windows of time to filter the entries you wish to see. Filtering by Message Interest We learned above some ways that you can filter the journal data using time constraints. In this section well discuss how to filter based on what service or component you are interested in. The systemd journal provides a variety of ways of doing this. Perhaps the most useful way of filtering is by the unit you are interested in. We can use the - u option to filter in this way. For instance, to see all of the logs from an Nginx unit on our system, we can type: Typically, you would probably want to filter by time as well in order to display the lines you are interested in. For instance, to check on how the service is running today, you can type: This type of focus becomes extremely helpful when you take advantage of the journals ability to interleave records from various units. For instance, if your Nginx process is connected to a PHP-FPM unit to process dynamic content, you can merge the entries from both in chronological order by specifying both units: This can make it much easier to spot the interactions between different programs and debug systems instead of individual processes. By Process, User, or Group ID Some services spawn a variety of child processes to do work. If you have scouted out the exact PID of the process you are interested in, you can filter by that as well. To do this we can filter by specifying the PID field. For instance if the PID were interested in is 8088, we could type: At other times, you may wish to show all of the entries logged from a specific user or group. This can be done with the UID or GID filters. For instance, if your web server runs under the www-data user, you can find the user ID by typing: Afterwards, you can use the ID that was returned to filter the journal results: The systemd journal has many fields that can be used for filtering. Some of those are passed from the process being logged and some are applied by journald using information it gathers from the system at the time of the log. The leading underscore indicates that the PID field is of the latter type. The journal automatically records and indexes the PID of the process that is logging for later filtering. You can find out about all of the available journal fields by typing: We will be discussing some of these in this guide. For now though, we will go over one more useful option having to do with filtering by these fields. The - F option can be used to show all of the available values for a given journal field. For instance, to see which group IDs the systemd journal has entries for, you can type: This will show you all of the values that the journal has stored for the group ID field. This can help you construct your filters. By Component Path We can also filter by providing a path location. If the path leads to an executable, journalctl will display all of the entries that involve the executable in question. For instance, to find those entries that involve the bash executable, you can type: Usually, if a unit is available for the executable, that method is cleaner and provides better info (entries from associated child processes, etc). Sometimes, however, this is not possible. Displaying Kernel Messages Kernel messages, those usually found in dmesg output, can be retrieved from the journal as well. To display only these messages, we can add the - k or --dmesg flags to our command: By default, this will display the kernel messages from the current boot. You can specify an alternative boot using the normal boot selection flags discussed previously. For instance, to get the messages from five boots ago, you could type: By Priority One filter that system administrators often are interested in is the message priority. While it is often useful to log information at a very verbose level, when actually digesting the available information, low priority logs can be distracting and confusing. You can use journalctl to display only messages of a specified priority or above by using the - p option. This allows you to filter out lower priority messages. For instance, to show only entries logged at the error level or above, you can type: This will show you all messages marked as error, critical, alert, or emergency. The journal implements the standard syslog message levels. You can use either the priority name or its corresponding numeric value. In order of highest to lowest priority, these are: The above numbers or names can be used interchangeably with the - p option. Selecting a priority will display messages marked at the specified level and those above it. Modifying the Journal Display Above, we demonstrated entry selection through filtering. There are other ways we can modify the output though. We can adjust the journalctl display to fit various needs. Truncate or Expand Output We can adjust how journalctl displays data by telling it to shrink or expand the output. By default, journalctl will show the entire entry in the pager, allowing the entries to trail off to the right of the screen. This info can be accessed by pressing the right arrow key. If youd rather have the output truncated, inserting an ellipsis where information has been removed, you can use the --no-full option: You can also go in the opposite direction with this and tell journalctl to display all of its information, regardless of whether it includes unprintable characters. We can do this with the - a flag: Output to Standard Out By default, journalctl displays output in a pager for easier consumption. If you are planning on processing the data with text manipulation tools, however, you probably want to be able to output to standard output. You can do this with the --no-pager option: This can be piped immediately into a processing utility or redirected into a file on disk, depending on your needs. Output Formats If you are processing journal entries, as mentioned above, you most likely will have an easier time parsing the data if it is in a more consumable format. Luckily, the journal can be displayed in a variety of formats as needed. You can do this using the - o option with a format specifier. For instance, you can output the journal entries in JSON by typing: This is useful for parsing with utilities. You could use the json-pretty format to get a better handle on the data structure before passing it off to the JSON consumer: The following formats can be used for display: cat . Displays only the message field itself. export . A binary format suitable for transferring or backing up. json . Standard JSON with one entry per line. json-pretty . JSON formatted for better human-readability json-sse . JSON formatted output wrapped to make add server-sent event compatible short . The default syslog style output short-iso . The default format augmented to show ISO 8601 wallclock timestamps. short-monotonic . The default format with monotonic timestamps. short-precise . The default format with microsecond precision verbose . Shows every journal field available for the entry, including those usually hidden internally. These options allow you to display the journal entries in the whatever format best suits your current needs. Active Process Monitoring The journalctl command imitates how many administrators use tail for monitoring active or recent activity. This functionality is built into journalctl. allowing you to access these features without having to pipe to another tool. Displaying Recent Logs To display a set amount of records, you can use the - n option, which works exactly as tail - n . By default, it will display the most recent 10 entries: You can specify the number of entries youd like to see with a number after the - n : Following Logs To actively follow the logs as they are being written, you can use the - f flag. Again, this works as you might expect if you have experience using tail - f : Journal Maintenance You may be wondering about the cost is of storing all of the data weve seen so far. Furthermore, you may be interesting in cleaning up some older logs and freeing up space. Finding Current Disk Usage You can find out the amount of space that the journal is currently occupying on disk by using the --disk-usage flag: Deleting Old Logs If you wish to shrink your journal, you can do that in two different ways (available with systemd version 218 and later). If you use the --vacuum-size option, you can shrink your journal by indicating a size. This will remove old entries until the total journal space taken up on disk is at the requested size: Another way that you can shrink the journal is providing a cutoff time with the --vacuum-time option. Any entries beyond that time are deleted. This allows you to keep the entries that have been created after a specific time. For instance, to keep entries from the last year, you can type: Limiting Journal Expansion You can configure your server to place limits on how much space the journal can take up. This can be done by editing the etcsystemdjournald. conf file. The following items can be used to limit the journal growth: SystemMaxUse . Specifies the maximum disk space that can be used by the journal in persistent storage. SystemKeepFree . Specifies the amount of space that the journal should leave free when adding journal entries to persistent storage. SystemMaxFileSize . Controls how large individual journal files can grow to in persistent storage before being rotated. RuntimeMaxUse . Specifies the maximum disk space that can be used in volatile storage (within the run filesystem). RuntimeKeepFree . Specifies the amount of space to be set aside for other uses when writing data to volatile storage (within the run filesystem). RuntimeMaxFileSize . Specifies the amount of space that an individual journal file can take up in volatile storage (within the run filesystem) before being rotated. By setting these values, you can control how journald consumes and preserves space on your server. Conclusion As you can see, the systemd journal is incredibly useful for collecting and managing your system and application data. Most of the flexibility comes from the extensive metadata automatically recorded and the centralized nature of the log. The journalctl command makes it easy to take advantage of the advanced features of the journal and to do extensive analysis and relational debugging of different application components. Almost there Report a Bug
No comments:
Post a Comment