404 Not Found

Os comandos acima s\u00e3o \u00fateis para iniciar ou parar comandos durante a sess\u00e3o atual. Para dizer ao systemd para iniciar os servi\u00e7os automaticamente no boot, voc\u00ea deve habilit\u00e1-los.<\/p>\n

Para iniciar um servi\u00e7o no boot, utilize o comando\u00a0enable<\/strong>:<\/p>\n

sudo systemctl enable application.service\r\n<\/code><\/pre>\n
Isto ir\u00e1 criar um link simb\u00f3lico de c\u00f3pia do sistema do arquivo de servi\u00e7o (normalmente em \/lib\/systemd\/system ou \/etc\/systemd\/system) para o local no disco onde systemd procura por arquivos de inicializa\u00e7\u00e3o autom\u00e1tica (geralmente \/etc\/systemd\/system\/some_target.target.wants . Mas vou passar o que um target mais adiante neste guia).<\/p>\n
Para desativar o servi\u00e7o que \u00e9\u00a0iniciado automaticamente, voc\u00ea pode usar o disable<\/strong>:<\/p>\n
sudo systemctl disable application.service\r\n<\/code><\/pre>\n
Isto ir\u00e1 remover o link simb\u00f3lico que indica que o servi\u00e7o deve ser iniciado automaticamente.<\/p>\n
Tenha em mente que habilitar um servi\u00e7o com o comando enable\u00a0n\u00e3o ir\u00e1 inici\u00e1-lo na sess\u00e3o atual. Se voc\u00ea deseja iniciar o servi\u00e7o e habilit\u00e1-lo no boot, voc\u00ea ter\u00e1 que usar os comandos\u00a0start\u00a0e enable<\/strong>.<\/p>\n
Verificando o Status de Servi\u00e7os<\/h3>\n
Para verificar o status de um servi\u00e7o em seu sistema, voc\u00ea pode usar o comando\u00a0status<\/strong>:<\/p>\n
systemctl status application.service\r\n<\/code><\/pre>\n
Isto ir\u00e1 fornecer-lhe com o estado do servi\u00e7o, a hierarquia cgroup, e as primeiras linhas de log.<\/p>\n
Por exemplo, ao verificar o status de um servidor Nginx, voc\u00ea poder\u00e1 ver uma sa\u00edda como esta:<\/p>\n
\u25cf nginx.service - A high performance web server and a reverse proxy server\r\n   Loaded: loaded (\/usr\/lib\/systemd\/system\/nginx.service; enabled; vendor preset: disabled)\r\n   Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago\r\n Main PID: 495 (nginx)\r\n   CGroup: \/system.slice\/nginx.service\r\n           \u251c\u2500495 nginx: master process \/usr\/bin\/nginx -g pid \/run\/nginx.pid; error_log stderr;\r\n           \u2514\u2500496 nginx: worker process\r\n\r\nJan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server...\r\nJan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server.<\/code><\/pre>\n
Isso lhe d\u00e1 uma boa vis\u00e3o geral do status atual da aplica\u00e7\u00e3o, notificando-o de todos os problemas e quaisquer a\u00e7\u00f5es que possam ser necess\u00e1rias.<\/p>\n
Existem tamb\u00e9m m\u00e9todos para a verifica\u00e7\u00e3o de estados espec\u00edficos. Por exemplo, para verificar se a unidade est\u00e1 ativa (em execu\u00e7\u00e3o), voc\u00ea pode usar o comando is-active<\/strong>:<\/p>\n
systemctl is-active application.service\r\n<\/code><\/pre>\n
Isto ir\u00e1 lhe retornar\u00a0o estado da unidade atual, que \u00e9 geralmente active\u00a0ou inactive.\u00a0O c\u00f3digo de sa\u00edda ser\u00e1 “0” se ele estiver ativo, tornando o resultado mais simples para analisar programaticamente.<\/p>\n
Para ver se a unidade for ativada, voc\u00ea pode usar o comando\u00a0is-enabled<\/strong>:<\/p>\n
systemctl is-enabled application.service\r\n<\/code><\/pre>\n
A sa\u00edda ser\u00e1 se o servi\u00e7o est\u00e1 enabled\u00a0ou disabled<\/strong>\u00a0e voltar\u00e1 a definir o c\u00f3digo de sa\u00edda para “0” ou “1”, dependendo da resposta \u00e0 pergunta do comando.<\/p>\n
Uma terceira verifica\u00e7\u00e3o \u00e9 se a unidade est\u00e1 em um estado de falha. Esta\u00a0indicar\u00e1\u00a0se\u00a0existe um problema ao iniciar a unidade em quest\u00e3o:<\/p>\n
systemctl is-failed application.service\r\n<\/code><\/pre>\n
Isso ir\u00e1 retornar active\u00a0se estiver funcionando corretamente ou failed<\/strong>\u00a0se ocorreu um erro. Se a unidade foi intencionalmente parada, ele pode retornar unknow\u00a0ou inactive<\/strong>. Um status de sa\u00edda “0” indica que ocorreu uma falha e um status de sa\u00edda “1” indica qualquer outro status.<\/p>\n
Vis\u00e3o Geral do Status do Sistema<\/h2>\n
Os comandos at\u00e9 agora t\u00eam sido \u00fateis para o gerenciamento de servi\u00e7os individuais, mas eles n\u00e3o s\u00e3o muito \u00fateis para explorar o estado atual do sistema. H\u00e1 uma s\u00e9rie de comandos\u00a0systemctl\u00a0<\/strong>que fornecem essas informa\u00e7\u00f5es.<\/p>\n
Listagem Unidades Atuais<\/h3>\n
Para ver uma lista de todas as unidades ativas que o Systemd conhece, podemos usar o comando\u00a0list-units:<\/strong><\/p>\n
systemctl list-units\r\n<\/code><\/pre>\n
Isto ir\u00e1 mostrar uma lista de todas as unidades que Systemd tem atualmente ativas no sistema. A sa\u00edda ser\u00e1 algo parecido com isto:<\/p>\n
UNIT                                      LOAD   ACTIVE SUB     DESCRIPTION\r\natd.service                               loaded active running ATD daemon\r\navahi-daemon.service                      loaded active running Avahi mDNS\/DNS-SD Stack\r\ndbus.service                              loaded active running D-Bus System Message Bus\r\ndcron.service                             loaded active running Periodic Command Scheduler\r\ndkms.service                              loaded active exited  Dynamic Kernel Modules System\r\ngetty@tty1.service                        loaded active running Getty on tty1\r\n\r\n. . .<\/code><\/pre>\n
A sa\u00edda possui as seguintes colunas:<\/p>\n
\n
UNIT<\/strong>: O nome da unidade do\u00a0systemd<\/li>\n
LOAD<\/strong>: Se a configura\u00e7\u00e3o da unidade foi analisada pelo systemd. A configura\u00e7\u00e3o das unidades carregadas s\u00e3o mantida na mem\u00f3ria.<\/li>\n
ACTIVE<\/strong>: Um resumo do estado se a unidade estiver ativa. Isso geralmente \u00e9 uma maneira bastante b\u00e1sica para mostrar\u00a0se a unidade foi iniciado com \u00eaxito ou n\u00e3o.<\/li>\n
SUB<\/strong>: Este \u00e9 um estado de n\u00edvel inferior que indica informa\u00e7\u00f5es mais detalhadas sobre a unidade. Isso muitas vezes varia por tipo de unidade, estado, e o m\u00e9todo real em que a unidade funciona.<\/li>\n
DESCRIPTION<\/strong>: Uma breve descri\u00e7\u00e3o textual do que a unidade \u00e9\/faz.<\/li>\n<\/ul>\n
Uma vez que o comando list-units\u00a0<\/strong>mostra apenas as unidades ativas, por padr\u00e3o, todas as entradas acima ir\u00e3o mostrar “loaded” na LOAD\u00a0e “active” na coluna ACTIVE. Esta exposi\u00e7\u00e3o \u00e9, na verdade, o comportamento padr\u00e3o do systemctl quando chamado sem comandos adicionais, ent\u00e3o voc\u00ea vai ver a mesma coisa se voc\u00ea chamar systemctl sem argumentos:<\/p>\n
systemctl\r\n<\/code><\/pre>\n
Podemos dizer systemctl\u00a0tr\u00e1s informa\u00e7\u00f5es de sa\u00eddas diferentes, adicionando flags\u00a0adicionais. Por exemplo, para ver todas as unidades que Systemd\u00a0carregou (ou tentou carregar), independentemente de se eles est\u00e3o ativos, voc\u00ea pode usar a flag\u00a0–all<\/strong>, como neste exemplo:<\/p>\n
systemctl list-units --all\r\n<\/code><\/pre>\n
Isto ir\u00e1 mostrar qualquer unidade que Systemd carregou ou tentou carregar, independentemente do seu estado atual no sistema. Algumas unidades se tornam inativas ap\u00f3s a execu\u00e7\u00e3o, e algumas unidades que Systemd<\/code> tentou carregar e pode por n\u00e3o ter sido encontrada no disco.<\/p>\n
Voc\u00ea pode usar outras flags\u00a0para filtrar esses resultados. Por exemplo, podemos usar o “–state =<\/strong>”\u00a0para indicar os estados LOAD, ativos ou SUB que desejar ver. Voc\u00ea ter\u00e1 que manter o sinalizador –all\u00a0<\/strong>para que o systemctl<\/strong>\u00a0permita que as unidades n\u00e3o ativas sejam\u00a0exibidas:<\/p>\n
systemctl list-units --all --state=inactive\r\n<\/code><\/pre>\n
Outro filtro comum \u00e9 o filtro –type=<\/strong>.\u00a0Podemos dizer ao systemctl\u00a0para mostrar somente unidades do tipo que estamos interessados em ver.\u00a0Por exemplo, para ver apenas as unidades do servi\u00e7o ativas, n\u00f3s podemos usar:<\/p>\n
systemctl list-units --type=service\r\n<\/code><\/pre>\n
Listando Todos os Arquivos da Unidade<\/h3>\n
O comando list-units<\/strong>\u00a0exibe apenas unidades que Systemd tentou analisar e carregar na mem\u00f3ria. Ent\u00e3o, o\u00a0systemd s\u00f3 vai ler unidades que acha que precisa, e isso n\u00e3o vai necessariamente incluir todas as unidades dispon\u00edveis no sistema. Para ver todos os arquivo de unidade dispon\u00edveis dentro dos caminhos de pasta do\u00a0Systemd, incluindo aqueles que systemd n\u00e3o tentou carregar, voc\u00ea pode usar o comando\u00a0list-units-files<\/strong>:<\/p>\n
systemctl list-units-files\r\n<\/code><\/pre>\n
Unidades s\u00e3o representa\u00e7\u00f5es de recursos que o\u00a0Systemd conhece. O\u00a0systemd n\u00e3o necessariamente l\u00ea todas as defini\u00e7\u00f5es de unidade neste ponto de vista, s\u00f3 apresenta informa\u00e7\u00f5es sobre os pr\u00f3prios arquivos. A sa\u00edda tem duas colunas: o arquivo de unidade e o estado.<\/p>\n
UNIT FILE                                  STATE   \r\nproc-sys-fs-binfmt_misc.automount          static  \r\ndev-hugepages.mount                        static  \r\ndev-mqueue.mount                           static  \r\nproc-fs-nfsd.mount                         static  \r\nproc-sys-fs-binfmt_misc.mount              static  \r\nsys-fs-fuse-connections.mount              static  \r\nsys-kernel-config.mount                    static  \r\nsys-kernel-debug.mount                     static  \r\ntmp.mount                                  static  \r\nvar-lib-nfs-rpc_pipefs.mount               static  \r\norg.cups.cupsd.path                        enabled\r\n\r\n. . .<\/code><\/pre>\n
O estado geralmente ser\u00e1 “enabled”, “disabled”, “static”, ou “masked”. <\/span>Neste contexto, “static” significa que o arquivo unidade n\u00e3o cont\u00e9m uma se\u00e7\u00e3o “install”, que \u00e9 usado para ativar uma unidade. Como tal, estas unidades n\u00e3o podem ser ativadas. Geralmente, isto significa que a unidade efetua uma a\u00e7\u00e3o de uma \u00fanica vez ou \u00e9 utilizado apenas como uma depend\u00eancia de outra unidade e n\u00e3o deve ser administrada por si s\u00f3. <\/span>E vamos dizer que o “masked” significa momentaneamente.<\/p>\n
Gest\u00e3o de unidade<\/h2>\n
At\u00e9 agora, temos trabalhado com os servi\u00e7os e exibido informa\u00e7\u00f5es sobre os arquivos e unidades que o\u00a0Systemd conhece. No entanto, podemos encontrar informa\u00e7\u00f5es mais espec\u00edficas sobre as unidades que usam alguns comandos adicionais.<\/p>\n
Exibindo Um Arquivo Unit<\/h3>\n
Para exibir que o arquivo de unidade do\u00a0systemd foi carregado no seu sistema, voc\u00ea pode usar o comando\u00a0cat<\/strong>\u00a0(este foi adicionado em systemd vers\u00e3o 209). Por exemplo, para ver o arquivo unidade do \u00a0daemon\u00a0atd\u00a0, poder\u00edamos escrever:<\/p>\n
systemctl cat atd.service\r\n<\/code><\/pre>\n
<\/code>[Unit]\r\nDescription=ATD daemon\r\n\r\n[Service]\r\nType=forking\r\nExecStart=\/usr\/bin\/atd\r\n\r\n[Install]\r\nWantedBy=multi-user.target<\/code><\/pre>\n
A sa\u00edda \u00e9 o arquivo\u00a0de unidade como \u00e9 conhecido na atualmente na\u00a0execu\u00e7\u00e3o do processo do\u00a0systemd. Isso pode ser importante se voc\u00ea tiver modificado arquivos da unidade recentemente ou se voc\u00ea est\u00e1 substituindo determinadas op\u00e7\u00f5es em um fragmento de arquivo da unidade (n\u00f3s iremos\u00a0cobrir isso mais tarde).<\/p>\n
Exibindo Depend\u00eancias<\/h3>\n
Para ver \u00e1rvore de depend\u00eancias de uma unidade, voc\u00ea pode usar o comando\u00a0list-dependencies<\/strong>:<\/p>\n
systemctl list-dependencies sshd.service\r\n<\/code><\/pre>\n
Isto ir\u00e1 exibir uma hierarquia mapeando as depend\u00eancias que devem ser tratadas com a fim de iniciar a unidade em quest\u00e3o. Depend\u00eancias, neste contexto, incluem as unidades que s\u00e3o ou “necess\u00e1rias” ou “requeridas” pelas unidades acima dela.<\/p>\n
sshd.service\r\n\u251c\u2500system.slice\r\n\u2514\u2500basic.target\r\n  \u251c\u2500microcode.service\r\n  \u251c\u2500rhel-autorelabel-mark.service\r\n  \u251c\u2500rhel-autorelabel.service\r\n  \u251c\u2500rhel-configure.service\r\n  \u251c\u2500rhel-dmesg.service\r\n  \u251c\u2500rhel-loadmodules.service\r\n  \u251c\u2500paths.target\r\n  \u251c\u2500slices.target\r\n\r\n. . .\r\n<\/code><\/pre>\n
As depend\u00eancias recursivas s\u00e3o exibidas apenas por unidades\u00a0.TARGET, que indicam estados do sistema. Para listar recursivamente todas as depend\u00eancias, inclua a flag\u00a0–all<\/strong>.<\/p>\n
Para mostrar depend\u00eancias reversas (unidades que dependem da unidade especificada), voc\u00ea pode adicionar o sinalizador –reverse<\/strong>\u00a0ao comando. Outras op\u00e7\u00f5es que s\u00e3o \u00fateis s\u00e3o os\u00a0–before<\/strong> e –after<\/strong>, que podem ser usadas para mostrar unidades que dependem da unidade especificada, come\u00e7ando antes e depois dela, respectivamente.<\/p>\n
Verifica\u00e7\u00e3o das Propriedades da Unidade<\/h3>\n
Para ver as propriedades de baixo n\u00edvel de uma unidade, voc\u00ea pode usar o programa de comando. Isto ir\u00e1 exibir uma lista de propriedades que est\u00e3o definidas para a unidade especificada usando um formato\u00a0chave=valor:<\/p>\n
systemctl show sshd.service \r\n<\/code><\/pre>\n
Id=sshd.service\r\nNames=sshd.service\r\nRequires=basic.target\r\nWants=system.slice\r\nWantedBy=multi-user.target\r\nConflicts=shutdown.target\r\nBefore=shutdown.target multi-user.target\r\nAfter=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice\r\nDescription=OpenSSH server daemon\r\n\r\n. . .<\/code><\/pre>\n
Se voc\u00ea quiser exibir uma \u00fanica propriedade, voc\u00ea pode usar\u00a0a flag\u00a0-p<\/strong>\u00a0com o nome da propriedade. Por exemplo, para ver os conflitos que a unidade\u00a0sshd.service\u00a0tem, voc\u00ea pode digitar:<\/p>\n
systemctl show sshd.service -p Conflicts\r\n<\/code><\/pre>\n
Conflicts=shutdown.target\r\n<\/code><\/pre>\n
Mascaramento e Desmascarando Unidades<\/h3>\n
Vimos na se\u00e7\u00e3o de gerenciamento de servi\u00e7os como parar ou desativar um servi\u00e7o, mas o\u00a0systemd\u00a0tamb\u00e9m tem a capacidade de marcar uma unidade como completamente\u00a0n\u00e3o-inici\u00e1vel, automaticamente ou manualmente, ligando-a \u00e0\u00a0\/dev\/null<\/strong>. Isto \u00e9 chamado de mascaramento da unidade, e \u00e9 poss\u00edvel com o comando\u00a0mask<\/strong>:<\/p>\n
sudo systemctl mask nginx.service\r\n<\/code><\/pre>\n
Isso ir\u00e1 impedir que o servi\u00e7o Nginx seja iniciado, manual ou automaticamente, durante o tempo que ele \u00e9 mascarado.<\/p>\n
Se voc\u00ea verificar as list-unit-files<\/strong>, voc\u00ea vai ver o servi\u00e7o agora est\u00e1 listado como mascarado:<\/p>\n
systemctl list-unit-files\r\n<\/code><\/pre>\n
. . .\r\n\r\nkmod-static-nodes.service              static  \r\nldconfig.service                       static  \r\nmandb.service                          static  \r\nmessagebus.service                     static  \r\nnginx.service                          masked<\/span>\r\nquotaon.service                        static  \r\nrc-local.service                       static  \r\nrdisc.service                          disabled\r\nrescue.service                         static\r\n\r\n. . .<\/code><\/pre>\n
Se voc\u00ea tentar iniciar o servi\u00e7o, voc\u00ea ver\u00e1 uma mensagem como esta:<\/p>\n
sudo systemctl start nginx.service\r\n<\/code><\/pre>\n
Failed to start nginx.service: Unit nginx.service is masked.\r\n<\/code><\/pre>\n
Para desmascarar uma unidade, tornando-a dispon\u00edvel para uso novamente, basta usar o comando unmask<\/strong>:<\/p>\n
sudo systemctl unmask nginx.service\r\n<\/code><\/pre>\n
Isso ir\u00e1 retornar a unidade ao seu estado anterior, permitindo-lhe ser habilitada.<\/p>\n
Editando Arquivos das Unidades<\/h2>\n
Enquanto o formato espec\u00edfico para arquivos de unidade est\u00e1 fora do escopo deste tutorial, o\u00a0systemctl\u00a0fornece mecanismos integrados para editar e modificar os arquivos da unidade se voc\u00ea precisar fazer ajustes. Esta funcionalidade foi adicionada no systemd vers\u00e3o 218.<\/p>\n
O comando edit, por padr\u00e3o, ir\u00e1\u00a0abrir para edi\u00e7\u00e3o a unidade em quest\u00e3o:<\/p>\n
sudo systemctl edit nginx.service\r\n<\/code><\/pre>\n
Este ser\u00e1 um arquivo em branco que pode ser usado para substituir ou adicionar diretrizes para a defini\u00e7\u00e3o da unidade. Um diret\u00f3rio ser\u00e1 criado dentro da etc\/systemd\/system\/\u00a0que ir\u00e1 conter\u00a0o nome da unidade com o sufixo “.d”. Por exemplo, para o nginx.service , um diret\u00f3rio chamado nginx.service.d ser\u00e1 criado.<\/p>\n
Dentro deste diret\u00f3rio, um arquivo ser\u00e1 criado chamado override.conf. Quando a unidade for carregada, o\u00a0systemd vai, na mem\u00f3ria, mesclar o arquico\u00a0de substitui\u00e7\u00e3o com o arquivo unidade completo. Diretivas do arquivo de configura\u00e7\u00e3o override.conf\u00a0ter\u00e1 preced\u00eancia sobre os encontrados no arquivo unidade original.<\/p>\n
Se voc\u00ea deseja editar o arquivo unidade completamente, em vez de criar um arquivo de override, voc\u00ea pode usar a flag\u00a0–full:<\/p>\n
sudo systemctl edit --full nginx.service\r\n<\/code><\/pre>\n
Isto ir\u00e1 carregar o arquivo de unidade atual para o editor, onde ele poder\u00e1 ser modificado. Ao sair do editor, o arquivo alterado ser\u00e1 gravado em \/etc\/systemd\/system, que ter\u00e1 preced\u00eancia sobre defini\u00e7\u00e3o de unidade do sistema (geralmente encontrado em \/lib\/systemd\/system).<\/p>\n
Para remover todas as adi\u00e7\u00f5es que voc\u00ea tenha feito, exclua o diret\u00f3rio de configura\u00e7\u00e3o da unidade .d\u00a0 ou o arquivo de servi\u00e7o modificado a partir de \/etc\/systemd\/system. Por exemplo:<\/p>\n
sudo rm -r \/etc\/systemd\/system\/nginx.service.d\r\n<\/code><\/pre>\n
Para remover completamente um arquivo de unidade modificada, use:<\/p>\n
sudo rm \/etc\/systemd\/system\/nginx.service\r\n<\/code><\/pre>\n
Depois de excluir o arquivo ou pasta, voc\u00ea deve recarregar o processo do\u00a0systemd\u00a0para que ele n\u00e3o tente fazer refer\u00eancia a esses arquivos e reverter usando c\u00f3pias do sistema. Voc\u00ea pode fazer isso digitando:<\/p>\n
sudo systemctl daemon-reload\r\n<\/code><\/pre>\n
Ajustando o Estado do Sistema (N\u00edvel de Execu\u00e7\u00e3o) com Targets<\/h2>\n
Os targets\u00a0s\u00e3o arquivos de unidade especiais que descrevem um ponto do estado<\/strong>\u00a0ou sincroniza\u00e7\u00e3o. Como outras unidades, os arquivos que definem os targets\u00a0podem ser identificados por seu sufixo, que neste caso \u00e9 o\u00a0.TARGET.\u00a0Targets\u00a0n\u00e3o fazem muito a si mesmos, mas s\u00e3o usados para agrupar unidades em conjunto<\/strong>.<\/p>\n
Isto pode ser utilizado, a fim de levar\u00a0o sistema para certos estados, assim\u00a0como outros sistemas de inicializa\u00e7\u00e3o como o init usam n\u00edveis de execu\u00e7\u00e3o (runlevel<\/strong>). Eles s\u00e3o usados como refer\u00eancia para quando certas fun\u00e7\u00f5es est\u00e3o dispon\u00edveis, permitindo que voc\u00ea especifique o estado desejado, em vez de unidades individuais necess\u00e1rias para produzir esse estado.<\/p>\n
Por exemplo, h\u00e1 um swap.target<\/strong> que \u00e9 usado para indicar que o swap\u00a0est\u00e1 pronto para uso. Unidades que fazem parte deste processo pode sincronizar com este target, indicando na sua configura\u00e7\u00e3o que eles s\u00e3o “WantedBy=<\/strong>” ou “RequiredBy=<\/strong>”\u00a0(Necess\u00e1rios ou requeridos) para que funcione o\u00a0swap.target. Unidades que requerem o swap podem especificar esta condi\u00e7\u00e3o usando os\u00a0WantedBy= ou RequiredBy=, e especifica\u00e7\u00f5es do\u00a0After=\u00a0para indicar a natureza de seu relacionamento.<\/p>\n
Obtendo e Definindo o Target\u00a0Padr\u00e3o<\/h3>\n
O processo do\u00a0systemd\u00a0tem um destino padr\u00e3o que ele usa durante a inicializa\u00e7\u00e3o do sistema. Satisfazendo a cascata de depend\u00eancias a partir desse \u00fanico target\u00a0vai trazer o sistema para o estado desejado. Para encontrar o destino padr\u00e3o para o seu sistema, digite:<\/p>\n
systemctl get-default\r\n<\/code><\/pre>\n
multi-user.target\r\n<\/code><\/pre>\n
Se voc\u00ea deseja definir\u00a0um target\u00a0padr\u00e3o diferente, voc\u00ea pode usar o set-default. Por exemplo, se voc\u00ea instalou um ambiente gr\u00e1fico desktop e voc\u00ea deseja que o sistema inicialize-o por padr\u00e3o, voc\u00ea pode mudar seu target\u00a0padr\u00e3o:<\/p>\n
sudo systemctl set-default graphical.target\r\n<\/code><\/pre>\n
Listando Targets\u00a0Dispon\u00edveis<\/h3>\n
Voc\u00ea pode obter uma lista dos targets\u00a0dispon\u00edveis no seu sistema digitando:<\/p>\n
systemctl list-units-files --type=target\r\n<\/code><\/pre>\n
Ao contr\u00e1rio de n\u00edveis de execu\u00e7\u00e3o, alvos m\u00faltiplos podem estar ativos ao mesmo tempo. Um alvo ativo indica que systemd tentou come\u00e7ar a todas as unidades ligadas ao alvo e n\u00e3o tentou derrub\u00e1-las novamente. Para ver todos os alvos ativos, digite:<\/p>\n
systemctl list-units --type=target\r\n<\/code><\/pre>\n
Isolando Targets<\/h3>\n
\u00c9 poss\u00edvel iniciar todas as unidades associadas com um alvo e parar todas as unidades que n\u00e3o s\u00e3o parte da \u00e1rvore de depend\u00eancia. O comando que n\u00f3s precisamos de fazer isso \u00e9 chamado, apropriadamente, isolate<\/strong>. Isto \u00e9 semelhante \u00e0 mudar o runlevel (n\u00edvel de execu\u00e7\u00e3o) em outros sistemas de inicializa\u00e7\u00e3o.<\/p>\n
Por exemplo, se voc\u00ea estiver operando em um ambiente gr\u00e1fico com graphical.target<\/strong> ativo, voc\u00ea pode desligar o sistema gr\u00e1fico e colocar o sistema em um estado de linha de comando multi-user, isolando o multi-user.target<\/strong>. Como\u00a0o graphical.target depende do\u00a0multi-user.target,\u00a0(mas n\u00e3o o contr\u00e1rio), todas as unidades gr\u00e1ficas ser\u00e3o interrompidas.<\/p>\n
Voc\u00ea pode querer dar uma olhada nas depend\u00eancias do alvo que voc\u00ea est\u00e1 isolando antes de realizar este procedimento para garantir que voc\u00ea n\u00e3o est\u00e1 parando servi\u00e7os vitais:<\/p>\n
systemctl list-dependencies multi-user.target\r\n<\/code><\/pre>\n
Quando estiver satisfeito com as unidades que ser\u00e3o mantidas ativas, voc\u00ea pode isolar o alvo digitando:<\/p>\n
sudo systemctl isolate multi-user.target\r\n<\/code><\/pre>\n
Usando Atalhos Para Eventos Importantes<\/h3>\n
H\u00e1 targets\u00a0definidos para eventos importantes como desligar ou reiniciar. No entanto, o\u00a0systemctl\u00a0tamb\u00e9m tem alguns atalhos que adicionam um pouco de funcionalidades adicionais.<\/p>\n
Por exemplo, para colocar o sistema no modo de recupera\u00e7\u00e3o (de um \u00fanico usu\u00e1rio), voc\u00ea pode simplesmente usar o comando rescue\u00a0em vez do\u00a0isolate rescue.target<\/strong>:<\/p>\n
sudo systemctl rescue\r\n<\/code><\/pre>\n
Isto ir\u00e1 fornecer a funcionalidade adicional de alertar todos os usu\u00e1rios logados sobre o evento.<\/p>\n
Para parar o sistema, voc\u00ea pode usar o comando halt:<\/p>\n
sudo systemctl halt\r\n<\/code><\/pre>\n
Para iniciar um desligamento completo, voc\u00ea pode usar o comando poweroff:<\/p>\n
sudo systemctl poweroff\r\n<\/code><\/pre>\n
Uma reinicializa\u00e7\u00e3o pode ser iniciada com o comando reboot:<\/p>\n
sudo systemctl reboot\r\n<\/code><\/pre>\n
Todos estes comandos alertam os usu\u00e1rios logados que o evento est\u00e1 ocorrendo, algo que simplesmente executando ou isolando o target\u00a0n\u00e3o iria\u00a0fazer. Note que na maioria das m\u00e1quinas que usam systemd, os comandos mais curtos, s\u00e3o abrevia\u00e7\u00f5es\u00a0dos comandos do systemd, para estas opera\u00e7\u00f5es e funcionam corretamente tamb\u00e9m.<\/p>\n
Por exemplo, para reiniciar o sistema, normalmente voc\u00ea pode digitar:<\/p>\n
sudo reboot\r\n<\/code><\/pre>\n
Conclus\u00e3o<\/h2>\n
At\u00e9 agora, voc\u00ea deve estar familiarizado com alguns dos recursos b\u00e1sicos dos comandos do\u00a0systemctl\u00a0 que lhe permitem interagir com e controlar o seu systemd. O utilit\u00e1rio\u00a0systemctl\u00a0ser\u00e1 o seu principal ponto de intera\u00e7\u00e3o para gerenciamento de servi\u00e7os e status do sistema.<\/p>\n
O\u00a0systemctl opera principalmente com o processo principal\u00a0systemd, mas existem outros componentes do ecossistema do\u00a0systemd\u00a0 que s\u00e3o controladas por outros utilit\u00e1rios.<\/p>\n
Outros recursos, como sess\u00f5es de gerenciamento de log e de usu\u00e1rio s\u00e3o manipulados por daemons separados e utilit\u00e1rios de gerenciamento (journald\/journalctl e logind\/loginctl\u00a0respectivamente). Dedicar tempo para se familiarizar com esses outros instrumentos e daemons far\u00e3o a gest\u00e3o do sistema uma tarefa mais f\u00e1cil.<\/p>\n
Para saber mais sobre o jounalctl por exemplo, veja este outro artigo abaixo.<\/p>\n
<\/a><\/p>\n
Abra\u00e7os,<\/p>\n
Cleuber<\/p>\n
fonte: digitalocean<\/p>\n
\n