Curso: Gerenciamento de Serviços e Agendamento de Tarefas no Linux

Objetivos de Aprendizagem

Ao final deste curso, você será capaz de:

• Compreender a diferença entre daemon e serviço
• Dominar systemd e systemctl
• Criar e gerenciar seus próprios serviços systemd
• Agendar tarefas com cron e at
• Realizar backups com rsync
• Gerenciar a rotação de logs com logrotate

---

Parte 1 – Introdução a Daemons e Serviços

1.1 Definição: O que é um daemon?

Um daemon (ou daemon em inglês) é um programa que roda em segundo plano, sem interface gráfica, e que trabalha silenciosamente para oferecer serviços essenciais ao sistema ou aos usuários.

Exemplos simples:

• sshd : permite conexões remotas via SSH
• httpd : servidor web Apache
• crond : agenda a execução de tarefas
• systemd : orquestra todos os outros serviços na inicialização

---

1.2 Definição Técnica: Natureza e Função de um Daemon

Um daemon é um processo de sistema independente, iniciado:

• ou na inicialização do sistema
• ou manualmente pelo administrador
• e que não para até ser explicitamente interrompido.

Ele é:

• desacoplado de qualquer terminal ou sessão de usuário (tty)
• frequentemente criado pelo processo init (PID 1), atualmente systemd na maioria das distribuições modernas.

---

1.3 Como os daemons são criados?

3 etapas:

1. Inicialização via arquivo de configuração ou script
2. Desacoplamento do terminal atual
3. Execução contínua, geralmente em loop infinito, até ser parado ou ocorrer falha

Nos sistemas modernos, o systemd cuida automaticamente dessa gestão via unidades .service.

---

1.4 Os nomes dos daemons terminam com d

Isso é uma convenção de nomenclatura:

• sshd → Secure Shell Daemon
• ftpd → FTP Daemon
• systemd → System Daemon
• rsyslogd → Remote SYSLOG Daemon

---

1.5 Lista de daemons comuns no Linux

Daemon	Função principal
sshd	Permite conexões SSH
crond	Gerencia tarefas agendadas
httpd	Fornece serviço web (Apache)
systemd	Controla serviços e a inicialização do sistema
rsyslogd	Gerencia a centralização de logs do sistema
cupsd	Gerencia impressão
ntpd	Sincroniza o horário com servidores NTP

---

1.6 Daemons vs Serviços

• Um daemon é um processo, um serviço é uma abstração lógica.
• Um serviço pode ser um daemon, mas nem sempre (ex: tmp.mount não é um processo, mas uma unidade).

Elemento	Daemon	Serviço
Natureza	Processo em segundo plano	Unidade gerenciada pelo systemd
Visível?	Não, exceto via ps, systemctl	Visível com systemctl
Exemplo	sshd	sshd.service

Um serviço é simplesmente systemd

Critério	Daemon	Serviço (systemd)
Definição	Programa que roda em segundo plano	Unidade gerenciada pelo systemd para iniciar e gerenciar um programa
Inicialização	Automática ou manual (geralmente na inicialização)	Gerenciado com systemctl (start, stop, enable, etc.)
Roda em segundo plano?	Sim	Nem sempre (ex: um script curto pode ser um serviço)
Gerenciado por systemctl?	Não, exceto se integrado como serviço	Sim
Requer arquivo .service	Não	Sim (ex: /etc/systemd/system/meu_servico.service)
Pode existir sem systemd	Sim (sistemas antigos, scripts manuais)	Não (serviço = unidade systemd)
Exemplos	sshd, cron, script infinito em segundo plano	nginx.service, docker.service, meu_script.service

Para lembrar:

• Um daemon é um programa.
• Um serviço é uma forma de gerenciar esse programa com systemd.

---

1.7 Controle de daemons

No systemd, todos os daemons são controlados via systemctl, com os seguintes comandos:

Ação	Comando
Iniciar	sudo systemctl start sshd
Parar	sudo systemctl stop sshd
Reiniciar	sudo systemctl restart sshd
Ver status	sudo systemctl status sshd
Ativar na inicialização	sudo systemctl enable sshd
Desativar na inicialização	sudo systemctl disable sshd

---

1.8 Resumo – Pontos-chave

• Um daemon é um processo sem interface, que fornece um serviço.
• Geralmente é iniciado na inicialização, gerenciado pelo systemd.
• Para ver, ativar, desativar ou reiniciar um daemon, usa-se systemctl.
• Todos os serviços de sistema modernos agora são unidades gerenciadas pelo systemd.

---

Parte 2 – Introdução ao systemd e systemctl

2.1 O que é systemd?

systemd é o sistema de inicialização padrão da maioria das distribuições Linux modernas (Ubuntu, Fedora, Debian, CentOS, etc.). Ele substitui o antigo SysVinit e serve para:

• Inicializar o sistema na inicialização (montagem de discos, inicialização de serviços, etc.)
• Gerenciar todos os serviços do sistema de forma centralizada
• Oferecer ferramentas integradas como systemctl, journalctl, systemd-analyze, systemd-nspawn, etc.

Vantagens do systemd:

• Inicialização mais rápida graças à inicialização paralela
• Reinício automático de serviços em caso de falha
• Gerenciamento avançado de dependências entre serviços
• Centralização dos logs

---

2.2 O papel do systemctl

systemctl é a principal ferramenta de linha de comando para interagir com o systemd.

Permite:

• Iniciar, parar ou reiniciar um serviço
• Ativar ou desativar um serviço na inicialização
• Obter o status de um serviço
• Exibir todos os serviços ativos ou inativos

---

2.3 Comandos fundamentais com systemctl

Ação	Comando
Iniciar um serviço	sudo systemctl start nome_do_serviço
Parar um serviço	sudo systemctl stop nome_do_serviço
Reiniciar um serviço	sudo systemctl restart nome_do_serviço
Recarregar a configuração	sudo systemctl reload nome_do_serviço
Verificar o status	systemctl status nome_do_serviço
Ativar serviço na inicialização	sudo systemctl enable nome_do_serviço
Desativar serviço na inicialização	sudo systemctl disable nome_do_serviço

Substitua nome_do_serviço pelo nome real do serviço (ex: sshd, nginx, apache2, etc.).

---

2.4 Visualização de serviços

Exibir todos os serviços ativos:

systemctl list-units --type=service --state=running

Exibir todos os serviços (ativos ou não):

systemctl list-units --type=service

---

2.5 Uso do journalctl para consultar logs

O systemd integra um sistema centralizado de logs: journald. Você pode consultar os logs com o comando journalctl.

Objetivo	Comando
Ver todos os logs	journalctl
Ver logs de um serviço específico	journalctl -u nome_do_serviço
Ver logs desde a última inicialização	journalctl -b
Acompanhar logs em tempo real	journalctl -f
Ver logs da última hora	journalctl --since "1 hour ago"

---

2.6 As unidades (units) no systemd

Uma unidade é um objeto que o systemd pode gerenciar. Cada unidade corresponde a um arquivo com uma extensão específica.

Tipo de unidade	Extensão	Exemplo
Serviço	.service	nginx.service
Montagem	.mount	home.mount
Socket	.socket	cups.socket
Target	.target	multi-user.target
Timer	.timer	logrotate.timer

---

2.7 Os targets do systemd

Um target representa um estado global do sistema, equivalente aos antigos runlevels.

Nome do target	Descrição
rescue.target	Modo de recuperação (acesso root apenas)
multi-user.target	Modo multiusuário sem interface gráfica
graphical.target	Modo com interface gráfica
default.target	Target padrão na inicialização

Alterar o target atual:

sudo systemctl isolate multi-user.target

---

2.8 Análise de desempenho da inicialização

Medir o tempo total de inicialização:

systemd-analyze

Listar serviços ordenados por tempo de carregamento:

systemd-analyze blame

Ver a cadeia de dependências críticas:

systemd-analyze critical-chain

---

2.9 Gerenciar reinicializações automáticas

Para forçar o reinício automático de um serviço após uma falha, modifique ou crie uma unidade .service com:

[Service]
ExecStart=/caminho/para/script
Restart=always
RestartSec=5

Isso reinicia o serviço 5 segundos após cada falha.

---

2.10 Resumo

• systemd é o gerenciador moderno de unidades dos sistemas Linux
• systemctl é a interface de linha de comando para interagir com o systemd
• Serviços, targets, sockets e outros recursos são chamados de unidades
• journalctl permite consultar os logs do sistema
• Ferramentas como systemd-analyze permitem analisar o desempenho na inicialização

---

Parte 3 – Criando e Gerenciando Seus Próprios Serviços com systemd

3.1 Objetivo desta parte

Compreender como:

• Criar uma unidade de serviço personalizada
• Integrar um script de sistema ao systemd
• Testar, ativar, desativar e reiniciar esse serviço

---

3.2 Estrutura de um arquivo .service

Os arquivos de serviço geralmente ficam em:

• /etc/systemd/system/ (unidades personalizadas e persistentes)
• /lib/systemd/system/ (unidades instaladas por pacotes)

Exemplo de arquivo webapp.service:

[Unit]
Description=Serviço personalizado para iniciar uma aplicação web
After=network.target

[Service]
ExecStart=/usr/local/bin/webapp
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Explicação das seções:

• [Unit]: dependências do serviço, descrição
• [Service]: comando a ser executado, política de reinício
• [Install]: target de ativação (aqui, nível multiusuário)

---

3.3 Etapas para criar um serviço systemd personalizado

Etapa 1 – Escrever ou localizar o script a ser executado

Exemplo:

sudo nano /usr/local/bin/webapp

Conteúdo do script:

#!/bin/bash
while true; do
  echo "Aplicação em execução" >> /var/log/webapp.log
  sleep 30
done

Tornar o script executável:

sudo chmod +x /usr/local/bin/webapp

---

Etapa 2 – Criar a unidade de serviço

sudo nano /etc/systemd/system/webapp.service

Copie o seguinte conteúdo:

[Unit]
Description=Web Application Custom Service
After=network.target

[Service]
ExecStart=/usr/local/bin/webapp
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

---

Etapa 3 – Ativar e iniciar o serviço

Recarregar o systemd para reconhecer o novo arquivo:

sudo systemctl daemon-reload

Ativar o serviço na inicialização:

sudo systemctl enable webapp

Iniciar o serviço:

sudo systemctl start webapp

---

Etapa 4 – Verificar o funcionamento

Exibir o status do serviço:

systemctl status webapp

Verificar os logs:

journalctl -u webapp

---

3.4 Modificar um serviço já existente

Se você modificar o arquivo .service:

1. Salve as alterações
2. Recarregue a configuração:

sudo systemctl daemon-reload

3. Reinicie o serviço:

sudo systemctl restart webapp

---

3.5 Remover um serviço personalizado

Desativar o serviço:

sudo systemctl disable webapp

Parar o serviço:

sudo systemctl stop webapp

Remover o arquivo de unidade:

sudo rm /etc/systemd/system/webapp.service

Recarregar o systemd:

sudo systemctl daemon-reload

---

3.6 Caso prático: Reinício automático de um script que travou

No bloco [Service], utilize:

Restart=always
RestartSec=5

Isso permite:

• Reinício automático após falha
• Espera de 5 segundos entre cada reinício

---

3.7 Caso prático: Serviço temporário não persistente

Criar um serviço que você deseja executar apenas uma vez, sem registrar para inicializações futuras:

sudo systemctl start /etc/systemd/system/webapp.service

Sem enable, o serviço não será iniciado no próximo boot.

---

3.8 Resumo

• Serviços personalizados systemd são definidos em arquivos .service
• Permitem integrar qualquer script ao sistema
• O uso dos comandos daemon-reload, enable, start, status é essencial
• Um bom serviço inclui uma política de reinício robusta
• A estrutura [Unit], [Service], [Install] é obrigatória

---

Anexo da parte 3 – Não é possível "matar" um serviço com kill ou lsof

Este anexo demonstra que não é possível parar permanentemente um serviço gerenciado pelo systemd usando kill, kill -9 ou atacando o processo (ex. via lsof / ss). O systemd o reinicia enquanto a política Restart=always estiver ativa. A única forma correta de pará-lo é systemctl stop (e eventualmente disable ou mask).

Verificar se o serviço está rodando e escrevendo no log

cat /var/log/webapp.log
cat /var/log/webapp.log | wc -l

Ver o PID do serviço

sudo systemctl status webapp

Você verá uma linha como: Main PID: 1234 (webapp).

Matar o processo com kill (SIGTERM)

sudo kill 1234

Depois, verifique novamente:

sudo systemctl status webapp

Você vai observar que o serviço volta a ficar active (running) com um novo PID: o systemd o reiniciou.

Mais agressivo: kill -9 (SIGKILL)

sudo kill -9 <NOVO_PID>
sudo systemctl status webapp

Mesmo resultado: o systemd reinicia novamente o processo, pois Restart=always.

Prova ao vivo

Em um terminal, acompanhe os logs do serviço:

sudo journalctl -u webapp -f

Você verá os reinícios sucessivos após cada kill ou kill -9.

A solução: parar via systemd

sudo systemctl stop webapp
sudo systemctl status webapp

Para evitar que o serviço reinicie no próximo boot ou seja reiniciado pelo systemd:

• Opção A (simples) – Desativar na inicialização

sudo systemctl disable webapp

• Opção B (forte) – Mascarar o serviço (impossível de iniciar)

sudo systemctl mask webapp

Após mask, nem mesmo systemctl start webapp poderá iniciá-lo até que você execute sudo systemctl unmask webapp.

Lembrete: sinais e ferramentas

Ação	Comando / ferramenta
Finalização "limpa" (SIGTERM)	kill -15 <PID> ou kill <PID>
Forçar parada (SIGKILL)	kill -9 <PID>
Ver quem usa portas / arquivos	sudo lsof -i, sudo lsof -i :80
Ver portas TCP/UDP em escuta	sudo ss -ltnp, sudo ss -lunp, sudo ss -ltnp | grep -i ...

Essas ferramentas servem para diagnosticar (qual processo está escutando em uma porta, etc.); para parar um serviço, é preciso usar systemctl stop.

---

Anexo da parte 3 (2) – Mesmo exercício com o serviço webapp (cenário tipo prova)

Este anexo repete a mesma demonstração do Anexo 1, mas usando apenas o serviço webapp criado na etapa 3 deste capítulo (script que escreve em /var/log/webapp.log), sem nginx nem Wiki.js. Pode servir de base para uma prova do tipo Serviços systemd e gerenciamento de processos.

Pré-requisito: o serviço webapp foi criado, ativado e iniciado como nas seções 3.2 e 3.3 (script /usr/local/bin/webapp, unidade /etc/systemd/system/webapp.service, Restart=always).

---

Etapa 1 – Verificação do serviço e do log

Verifique se o serviço está rodando e escrevendo no log:

cat /var/log/webapp.log
cat /var/log/webapp.log | wc -l
sudo systemctl status webapp

Na saída do systemctl status webapp, anote a linha Main PID: XXXX (webapp).

---

Etapa 2 – Tentativa de parada manual (kill)

Substitua <PID> pelo Main PID exibido:

sudo kill -15 <PID>
# ou simplesmente: sudo kill <PID>

Depois, verifique novamente:

sudo systemctl status webapp

Observação: o serviço volta a ficar active (running) com um novo PID; o systemd o reiniciou por causa do Restart=always.

---

Etapa 3 – Tentativa mais agressiva (kill -9)

Use o novo PID exibido pelo systemctl status webapp:

sudo kill -9 <NOVO_PID>
sudo systemctl status webapp

Observação: mesmo resultado — o systemd reinicia novamente o processo.

---

Etapa 4 – Prova ao vivo (journalctl)

Em um terminal, acompanhe os logs do serviço para ver os reinícios após cada kill:

sudo journalctl -u webapp -f

---

Etapa 5 – Identificação do serviço (se partíssemos do processo)

Se tivéssemos apenas um PID ou uma porta, poderíamos identificar o serviço assim:

systemctl list-units --type=service --state=running | grep -i webapp
ps aux | grep webapp
ls -l /etc/systemd/system/ | grep webapp

Para um serviço escutando em uma porta (ex. 3000), também usaríamos:

sudo lsof -i -P -n | grep 3000
sudo ss -ltnp | grep 3000

Aqui, webapp não escuta em nenhuma porta; apenas preenche /var/log/webapp.log.

---

Etapa 6 – Solução: parada e desativação via systemd

Parada imediata:

sudo systemctl stop webapp
sudo systemctl status webapp

Desativação na inicialização (o serviço não reiniciará no próximo boot):

sudo systemctl disable webapp

Opção mais forte — mascarar o serviço (impossível de iniciar enquanto estiver mascarado):

sudo systemctl mask webapp

Para remover o mask depois: sudo systemctl unmask webapp.

---

Ferramentas complementares (bônus) – Investigação e diagnóstico

Esses comandos permitem aprofundar a investigação sobre serviços e portas. São úteis em provas ou troubleshooting.

1. systemd-cgls — Árvore dos grupos de controle (cgroups)

Exibe a hierarquia dos cgroups gerenciados pelo systemd: cada serviço (incluindo webapp) vive em uma subárvore. Útil para ver como o systemd agrupa processos.

systemd-cgls

Para ver apenas a parte do nosso serviço:

systemd-cgls | grep -A 5 webapp

Para que serve? Entender que o systemd isola e rastreia cada unidade em um cgroup; isso explica porque um simples kill do processo não "desinscreve" o serviço — o systemd monitora a unidade e a reinicia conforme Restart=always.

2. ss -lptn — Portas TCP em escuta e processos

Lista os sockets TCP em escuta com o PID e o programa associado (-l escuta, -p processo, -t TCP, -n portas em numérico).

sudo ss -lptn

Exemplo de saída (trecho):

LISTEN  0  128  *:80    *:*  users:(("nginx",pid=1234,fd=6))
LISTEN  0  128  *:3000  *:*  users:(("node",pid=5678,fd=21))

No nosso contexto: o serviço webapp da etapa 3 não escuta em nenhuma porta (apenas escreve em /var/log/webapp.log). Se você criar depois um serviço que escute na porta 3000 (ex. uma API ou proxy), verá aqui. É o equivalente moderno do netstat -lptn, mais rápido.

3. fuser -k 3000/tcp — Matar processos que usam uma porta

fuser indica quais processos usam um arquivo ou porta. A opção -k envia SIGKILL para esses processos.

Exemplo para a porta 3000 (usar se um serviço escuta nessa porta):

sudo fuser -k 3000/tcp

Comportamento didático: se um serviço systemd (ex. um futuro "webapp-api") escutasse na porta 3000 com Restart=always, após fuser -k 3000/tcp o processo seria morto, mas o systemd o reiniciaria e a porta voltaria a ser ocupada. Para liberar a porta de forma definitiva, é preciso systemctl stop <serviço> (e eventualmente disable).

Sem -k, apenas exibe os PIDs sem matar: sudo fuser -v 3000/tcp.

4. journalctl -u webapp — Logs do serviço (equivalente ao journalctl -u wikijs.service)

Exibe todas as mensagens do journald para a unidade webapp (inicializações, paradas, reinícios, erros).

journalctl -u webapp

Variações úteis:

Comando	Efeito
journalctl -u webapp	Todos os logs do serviço
journalctl -u webapp -f	Acompanhar logs em tempo real (como tail -f)
journalctl -u webapp -n 50	As últimas 50 linhas
journalctl -u webapp --since "1 hour ago"	Logs da última hora

Para que serve? Ver a prova de que o systemd reinicia o serviço após um kill ou fuser -k, e diagnosticar erros na inicialização.

---

Síntese (tipo prova)

Ação	Comando	Eficaz?
Parar o processo com um sinal	kill -15 <PID> ou kill -9 <PID>	Não — o systemd reinicia o serviço
Parar o serviço corretamente	sudo systemctl stop webapp	Sim
Evitar reinício no boot	sudo systemctl disable webapp	Sim
Impedir qualquer inicialização (mesmo manual)	sudo systemctl mask webapp	Sim

Para lembrar: com um serviço systemd configurado com Restart=always, kill e kill -9 não bastam; é preciso usar systemctl stop, depois disable (e eventualmente mask) para uma desativação definitiva.

---

Parte 4 – Agendamento de Tarefas com cron

4.1 Introdução

cron é uma ferramenta que permite programar tarefas repetitivas no Linux. O daemon crond roda em segundo plano e lê os arquivos crontab para executar comandos em data/hora específicas.

---

4.2 Estrutura de uma tarefa cron

*     *     *     *     *   comando a ser executado
-     -     -     -     -
|     |     |     |     |
|     |     |     |     +----- dia da semana (0 a 6, domingo = 0)
|     |     |     +----------- mês (1 a 12)
|     |     +----------------- dia do mês (1 a 31)
|     +----------------------- hora (0 a 23)
+---------------------------- minuto (0 a 59)

---

4.3 Dica para treinar rapidamente

Editar o crontab para o usuário atual:

crontab -e

Exibir as tarefas cron existentes:

crontab -l

---

4.4 Exercício 1 – Backup de /etc todos os domingos às 3h

Objetivo:

Criar um script que arquiva /etc em /var/backups.

Etapas:

1. Criar uma pasta de exercícios:

mkdir ~/cron_tp && cd ~/cron_tp

2. Criar um arquivo backup.sh:

nano backup.sh

Conteúdo:

#!/bin/bash
tar -czf /var/backups/etc-backup-$(date +%Y%m%d).tar.gz /etc

3. Tornar o script executável:

chmod +x backup.sh

4. Criar a pasta de destino se necessário:

sudo mkdir -p /var/backups

5. Adicionar ao crontab:

crontab -e

Adicionar a linha:

0 3 * * 0 /home/usuario/cron_tp/backup.sh

Substitua usuario pelo seu nome de usuário Linux.

---

4.5 Exercício 2 – Divirta-se com texto

Objetivo:

Escrever "Olá! Hoje é [data]" a cada 5 minutos em um arquivo.

Comando no crontab:

*/5 * * * * echo "Olá! Hoje é $(date)" >> /tmp/ola.txt

Depois, verifique:

tail /tmp/ola.txt

---

4.6 Exercício 3 – Criar uma página web dinâmica que muda a cada minuto

Objetivo:

Baixar diferentes páginas web a cada minuto e exibi-las na pasta web.

Etapas:

1. Criar um arquivo mypage.sh:

nano ~/cron_tp/mypage.sh

Conteúdo:

#!/bin/bash
urls=("www.yahoo.com" "www.cmaisonneuve.qc.ca" "www.crosemont.qc.ca" "www.netflix.com")

index_file="/home/$USER/index.txt"
backup_dir="/var/www/html"

index=0
if [[ -f "$index_file" ]]; then
  read -r index < "$index_file"
fi

url=${urls[$((index % ${#urls[@]}))]}
wget -qO "$backup_dir/index.html" --timeout=10 "$url"

next_index=$(( (index + 1) % ${#urls[@]} ))
echo "$next_index" > "$index_file"

2. Tornar o script executável:

chmod +x ~/cron_tp/mypage.sh

3. Agendar a tarefa a cada minuto:

crontab -e

Adicionar:

* * * * * /home/usuario/cron_tp/mypage.sh

4. Testar acessando:

http://localhost/index.html

A cada minuto, a página mudará automaticamente.

---

4.7 Exercício 4 – Observar processos e usuários

Objetivo:

Observar quem está conectado e quais processos estão rodando entre 9h e 17h.

Adicionar ao crontab:

# Todas as horas entre 9h e 17h: processos
0 9-17 * * 1-5 ps aux >> /var/log/processos.txt

# A cada 5 minutos entre 9h e 17h: usuários conectados
*/5 9-17 * * 1-5 who >> /var/log/quem.txt

Depois, visualize:

tail /var/log/processos.txt
tail /var/log/quem.txt

---

4.8 Dica: testar tarefas cron ao vivo

Para garantir que tudo funciona:

1. Coloque uma tarefa a cada minuto:

* * * * * echo "Tarefa teste em $(date)" >> ~/cron.log

2. Execute:

tail -f ~/cron.log

Espere um minuto: a linha aparecerá automaticamente.

---

4.9 Resumo

• cron permite executar scripts em horários específicos, automaticamente.
• Um script cron deve ser executável e especificar um caminho absoluto.
• Você pode observar os resultados com tail, ou criar arquivos .log para verificar seus testes.
• Esse sistema permite fazer backups, testes automatizados ou atualizar dinamicamente serviços.

---

Parte 5 – Tarefas Pontuais com at

5.1 O que é at?

O programa at permite agendar uma tarefa única para ser executada mais tarde, apenas uma vez (ao contrário do cron, que é repetitivo).

É perfeito para:

• Agendar um reinício do sistema
• Executar um script de processamento diferido
• Automatizar uma operação sensível em um momento específico

---

5.2 Verificação e instalação do serviço atd

Antes de tudo, certifique-se de que o daemon atd está ativo:

sudo systemctl start atd
sudo systemctl enable atd
sudo systemctl status atd

Se at não estiver instalado:

sudo apt install at   # Debian/Ubuntu
sudo yum install at   # CentOS/RHEL

---

5.3 Sintaxe básica

at <hora ou momento>

Exemplos:

at now + 1 minute
at 17:00
at 09:30 tomorrow
at now + 2 days

Uma vez no editor at>, digite o comando a ser executado e finalize com Ctrl + D.

---

5.4 Exercício 1 – Agendar uma mensagem para depois

Objetivo:

Exibir uma mensagem no seu terminal em 1 minuto.

1. Execute o comando:

at now + 1 minute

2. No prompt at>, digite:

echo "Esta é uma mensagem agendada com at"

3. Finalize com:

Ctrl + D

4. Aguarde um minuto e verifique se a mensagem aparece.

---

5.5 Exercício 2 – Script diferido em outro terminal

Objetivo:

Exibir uma mensagem em outro terminal (ex: /dev/pts/0).

1. Crie um script tratamento.sh:

nano ~/cron_tp/tratamento.sh

Conteúdo:

#!/bin/bash
echo "Mensagem diferida no terminal /dev/pts/0" > /dev/pts/0

2. Torne o script executável:

chmod +x ~/cron_tp/tratamento.sh

3. Agende o script:

at now + 2 minutes -f ~/cron_tp/tratamento.sh

Abra o terminal pts/0 em paralelo e observe.

---

5.6 Gerenciamento de tarefas at

Ação	Comando
Ver tarefas agendadas	atq ou at -l
Remover uma tarefa (ID = 5, por ex.)	atrm 5 ou at -d 5
Ver o conteúdo da tarefa ID 5	at -c 5

---

5.7 Controle de acesso ao at

Arquivo	Função
/etc/at.allow	Apenas os usuários listados aqui podem usar o at
/etc/at.deny	Todos os usuários exceto os listados aqui podem usar o at

Prioridade:

• Se at.allow existir, apenas os usuários nesse arquivo têm permissão.
• Caso contrário, aplica-se o at.deny.

Exemplo: bloquear toto

echo toto >> /etc/at.deny

---

5.8 Exercício 3 – Agendar um reinício sexta-feira às 17h

Objetivo:

Automatizar um reinício em uma data específica.

1. Digite:

at 17:00 Fri

2. No prompt at>, insira:

sudo /sbin/shutdown -r now

3. Finalize com Ctrl + D

Nota: Para testar sem reiniciar, use echo "Reinício agendado" no lugar.

---

5.9 Exercício 4 – Script automático em 2 dias

1. Crie um script simples:

echo "echo Processamento concluído em 2 dias" > ~/cron_tp/futuro.sh
chmod +x ~/cron_tp/futuro.sh

2. Agende-o:

at now + 2 days -f ~/cron_tp/futuro.sh

---

5.10 Resumo

• at é útil para tarefas pontuais, únicas, agendadas.
• Ele é complementar ao cron, que é cíclico.
• Você pode observar o efeito imediatamente com echo, ou construir scripts diferidos.

---

Parte 6 – Backups Avançados e Agendados com rsync

6.1 Por que usar rsync?

rsync é uma ferramenta poderosa de sincronização que permite copiar arquivos:

• localmente ou entre duas máquinas
• de forma otimizada (copia apenas arquivos modificados)
• com compressão, filtragem, backup e registro de logs

É ideal para:

• backups regulares
• migrações de servidores
• cópias diferenciais rápidas

---

6.2 Sintaxe básica

rsync [opções] origem destino

Exemplo simples:

rsync -av /home/user/documents /mnt/backup/

Opções frequentes:

• -a: archive (preserva permissões, links, datas)
• -v: verbose (exibe o que está sendo copiado)
• --delete: remove arquivos ausentes na origem
• --bwlimit=KBps: limita a banda utilizada

---

6.3 Exercício 1 – Backup local com limitação de banda

Objetivo:

Fazer backup da pasta /home em /mnt/backup todas as noites às 20h, sem saturar a banda.

Etapas:

1. Criar o script:

mkdir -p ~/cron_tp
nano ~/cron_tp/sync_home.sh

Conteúdo:

#!/bin/bash
rsync -av --delete --bwlimit=200 /home/ /mnt/backup/

2. Tornar o script executável:

chmod +x ~/cron_tp/sync_home.sh

3. Adicionar no crontab:

crontab -e

Adicionar:

0 20 * * * /home/usuario/cron_tp/sync_home.sh

(Substitua usuario pelo seu nome real)

---

6.4 Exercício 2 – Sincronização remota

Objetivo:

Sincronizar /var/www para outro servidor via SSH.

1. Comando direto (teste manual antes de automatizar):

rsync -avz -e ssh /var/www user@remote_host:/backup/www

2. Script automatizado:

nano ~/cron_tp/rsync_remote.sh

Conteúdo:

#!/bin/bash
rsync -az -e ssh /var/www user@192.168.0.100:/backup/www

3. Crontab (execução diária às 01h):

0 1 * * * /home/usuario/cron_tp/rsync_remote.sh

Pré-requisitos:

• acesso SSH sem senha (chave pública/privada configurada)
• permissões de escrita em /backup/www na máquina remota

---

6.5 Exercício 3 – Backup apenas à noite

Objetivo:

Limitar a execução do rsync ao horário não comercial (19h às 7h). Parar qualquer processo rsync durante o dia.

Etapas:

1. Script de início do rsync:

crontab -e

Adicionar:

0 19 * * * /home/usuario/cron_tp/sync_home.sh

2. Script de parada de segurança:

0 7 * * * pkill rsync

Isso garante que:

• rsync começa às 19h
• Se ainda estiver ativo às 7h, será encerrado

---

6.6 Exercício 4 – Backup com registro de logs

1. Script:

nano ~/cron_tp/rsync_logged.sh

Conteúdo:

#!/bin/bash
date >> /var/log/rsync_backup.log
rsync -av --delete /home /mnt/backup >> /var/log/rsync_backup.log 2>&1

2. Agendamento diário:

0 22 * * * /home/usuario/cron_tp/rsync_logged.sh

3. Leitura do log:

tail -n 20 /var/log/rsync_backup.log

---

6.7 Resumo

• rsync é uma ferramenta rápida, inteligente e controlável
• Pode ser limitado em banda com --bwlimit
• Pode ser automatizado com cron
• Pode ser restrito a determinados horários
• Permite registro completo para auditoria e acompanhamento

---

Parte 7 – Gerenciamento de Logs e Rotação com logrotate

7.1 Por que usar logrotate?

Os logs do sistema (em /var/log/) crescem continuamente com o tempo:

• Podem lotar o disco
• Ficam difíceis de consultar
• Podem reduzir o desempenho se mal gerenciados

logrotate permite:

• Fazer rotação automática de logs
• Excluir ou comprimir arquivos antigos
• Manter um histórico limitado no tempo
• Executar um comando após a rotação (ex: reiniciar um serviço)

---

7.2 Funcionamento geral

O logrotate geralmente é executado diariamente pelo cron, via:

/etc/cron.daily/logrotate

Ele lê a configuração global:

/etc/logrotate.conf

E as configurações específicas:

/etc/logrotate.d/

---

7.3 Sintaxe de um arquivo de configuração

Exemplo:

/var/log/webapp.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
    postrotate
        systemctl restart webapp
    endscript
}

Explicações:

• weekly: rotação semanal
• rotate 4: manter 4 arquivos antigos
• compress: comprimir os logs antigos
• missingok: não exibir erro se o arquivo não existir
• notifempty: não rotacionar se o arquivo estiver vazio
• postrotate: executar um comando após a rotação

---

7.4 Exercício 1 – Rotação de um log personalizado

Objetivo:

Rotacionar /var/log/rsync_backup.log semanalmente, mantendo 4 versões comprimidas.

1. Criar o arquivo /etc/logrotate.d/rsync_backup:

sudo nano /etc/logrotate.d/rsync_backup

2. Conteúdo:

/var/log/rsync_backup.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}

3. Testar a configuração:

sudo logrotate /etc/logrotate.conf --debug

4. Forçar a rotação para teste:

sudo logrotate /etc/logrotate.conf --force

5. Verificar:

ls -lh /var/log/rsync_backup*

---

7.5 Exercício 2 – Rotação com reinício de serviço

Objetivo:

Rotacionar /var/log/webapp.log e reiniciar o serviço webapp.

1. Criar o arquivo:

sudo nano /etc/logrotate.d/webapp

2. Conteúdo:

/var/log/webapp.log {
    weekly
    rotate 2
    compress
    missingok
    notifempty
    postrotate
        systemctl restart webapp
    endscript
}

3. Forçar uma rotação para testar:

sudo logrotate -f /etc/logrotate.conf

---

7.6 Exercício 3 – Rotação e envio por e-mail (simulação)

Objetivo:

Enviar as 100 últimas linhas do arquivo /var/log/syslog toda noite à meia-noite.

1. Adicionar no crontab:

crontab -e

Conteúdo:

0 0 * * * tail -n 100 /var/log/syslog | mail -s "Últimos logs do sistema" seuemail@email.com

2. Para testar o envio localmente:

mail

Pré-requisito: o sistema deve ter um agente de e-mail instalado (mailutils, sendmail, postfix...).

---

7.7 Exercício 4 – Rotação personalizada de um arquivo simulado

1. Crie um log falso:

echo "linha teste" >> /tmp/test.log

2. Crie o arquivo /etc/logrotate.d/testlog:

sudo nano /etc/logrotate.d/testlog

Conteúdo:

/tmp/test.log {
    daily
    rotate 3
    compress
    missingok
    notifempty
}

3. Force a rotação:

sudo logrotate -f /etc/logrotate.conf

4. Observe os arquivos:

ls -lh /tmp/test.log*

---

7.8 Resumo

• logrotate gerencia o tamanho, frequência, retenção e compressão dos logs
• Integra-se perfeitamente com o cron (via /etc/cron.daily/logrotate)
• Pode reiniciar serviços ou enviar e-mails
• Os arquivos de configuração personalizados ficam em /etc/logrotate.d/

---

Parte 8 – Quiz Final e Avaliação Prática

8.1 Objetivo pedagógico

Validar que o aluno sabe:

• Criar, ativar e monitorar um serviço systemd personalizado
• Agendar tarefas repetitivas e pontuais com cron e at
• Sincronizar pastas com rsync e limitar a banda
• Gerenciar a rotação de logs com logrotate
• Usar as ferramentas corretas de monitoramento (systemctl, journalctl, logrotate, etc.)

---

8.2 Parte A – Leitura e análise do crontab (5 pontos)

Explique o que faz cada linha a seguir:

1. 0 3 * * 0 /usr/local/bin/backup.sh
2. */10 9-17 * * 1-5 who >> /var/log/connected.log
3. @reboot systemctl restart nginx
4. 0 19 * * * /home/user/sync.sh
5. 0 7 * * * pkill rsync

---

8.3 Parte B – Criação de serviço systemd (15 pontos)

Você deve criar um serviço chamado weather_logger que:

• Executa um script /usr/local/bin/weather.sh
• Escreve a temperatura em /var/log/weather.log a cada 5 minutos (via cron)
• O serviço deve se reiniciar automaticamente em caso de falha
• Fornecer o arquivo weather_logger.service
• Ativar e iniciar o serviço
• Verificar seu status e logs

---

8.4 Parte C – Agendamento diferido com at (5 pontos)

1. Crie um script /home/user/alert.sh que envia a mensagem "Teste de segurança concluído" para o arquivo /tmp/alerta.log.
2. Agende esse script para ser executado em 2 horas exatamente a partir de agora.

---

8.5 Parte D – Sincronização rsync (10 pontos)

Crie um script sync_project.sh que:

• Faz backup da pasta /home/user/projects/ para /mnt/sauvegardes/
• Remove arquivos obsoletos (--delete)
• Limita a banda a 150 KB/s
• Registra as ações em /var/log/sync.log

Agende esse script para ser executado todas as noites às 22h.

---

8.6 Parte E – Rotação de logs com logrotate (10 pontos)

1. Crie um arquivo de configuração /etc/logrotate.d/weather para o arquivo /var/log/weather.log

2. Requisitos:

   • Rotação semanal
   • 3 arquivos mantidos
   • Compressão ativada
   • Rotação mesmo se vazio
   • Reinício do serviço weather_logger após a rotação

---

8.7 Parte F – Estudo de caso final: cenário completo (15 pontos)

Contexto: Você gerencia um servidor Linux onde roda uma aplicação personalizada (/usr/local/bin/monitor.py).

Objetivos:

1. Criar um serviço monitor.service que executa esse script na inicialização do sistema.
2. Agendar um backup do diretório /opt/monitoring todos os dias às 1h em /mnt/monitor_backup com rsync, limitado a 250 KB/s.
3. Criar um arquivo /etc/logrotate.d/monitoring.log para /var/log/monitoring.log, com rotação a cada 2 dias, mantendo 5 logs comprimidos.
4. Enviar as 100 últimas linhas de /var/log/syslog por e-mail todas as manhãs às 6h para admin@example.com.

---

8.8 Critérios de avaliação (de 60 pontos)

Parte	Pontos
A – Análise do crontab	5
B – Serviço systemd	15
C – Agendamento com at	5
D – Script rsync	10
E – logrotate personalizado	10
F – Caso completo	15

---

8.9 Instruções finais

• Todos os scripts devem ser executáveis (chmod +x)

• Os caminhos devem ser absolutos

• Você deve mostrar a saída de:

  • systemctl status
  • journalctl -u
  • ls -lh nos diretórios de logs e backups

---

Capítulo criado em: Dezembro de 2024