Introdução
DAYMARK já tem um script publicador seguro neste ambiente novo. Agora a equipe precisa de um agendamento real executado por uma conta dedicada a relatórios. Sucesso manual no terminal não demonstra que uma tarefa agendada consegue encontrar ou ler sua entrada.
Você configurará um serviço e um timer systemd correspondentes, observará acionamentos reais repetidos e depois se recuperará de erros de diretório e entrada sem perder o último relatório. Daymark é o site do negócio; Workstation começa em /srv/daymark-sales. Basta o uso básico do terminal; os conceitos do script de shell do laboratório guiado anterior são reutilizados. O calculador e o script fornecidos não exigem instalação.
Executar a exportação com um timer real
Nesta etapa, você estabelecerá o resultado correto do negócio e deixará systemd executar a exportação duas vezes. Comece em Daymark. Abra Records: a origem inicial contém 11 unidades no valor de 3450 centavos. Reports ainda oferece o fechamento anterior, TOTAL,1,100. A tarefa deve substituir esse arquivo pelo fechamento real.
Mude para Workstation. Este ambiente é independente: o script correto já está preparado, mas nenhum timer de relatórios foi instalado. cat imprime arquivos e pwd imprime seu diretório atual:
pwd
cat publish.sh
O script escreve ao lado do destino e renomeia somente após um cálculo bem-sucedido. Aceita argumentos de entrada e saída. id exibe a identidade da conta; ls -ld exibe propriedade e bits de acesso do diretório. Um diretório precisa de permissão de busca para ser atravessado e de escrita para criar arquivos.
id daymark-report
ls -ld reports
A conta de sistema preparada é proprietária de reports/. A leitura da entrada e a busca nos diretórios superiores permitem ler orders.csv; a propriedade do diretório de relatórios permite publicar. Não use root nem escrita para todos como atalho.
systemd é o gerenciador de serviços desta instância. Um arquivo .service descreve uma execução; seu .timer de mesmo nome informa quando solicitá-la. Type=oneshot espera a tarefa finita terminar. User escolhe a conta real de execução. WorkingDirectory define onde o orders.csv relativo será resolvido. ExecStart usa caminhos absolutos para executável, script e saída. O diretório do terminal e as configurações interativas do shell não são transmitidos a um serviço do sistema. Deixe RemainAfterExit sem definição: uma tarefa concluída precisa ficar inativa para que o próximo evento possa executá-la outra vez.
sudo tee FILE escreve um arquivo protegido e também o imprime. <<'UNIT' é um here-document entre aspas; cole até a palavra final correspondente. Crie apenas as unidades D10 indicadas:
sudo tee /etc/systemd/system/d10-sales.service <<'UNIT'
[Unit]
Description=Daymark sales export
[Service]
Type=oneshot
User=daymark-report
WorkingDirectory=/srv/daymark-sales
ExecStart=/bin/bash /srv/daymark-sales/publish.sh orders.csv /srv/daymark-sales/reports/sales.csv
UNIT
Este timer de treinamento começa cinco segundos após sua ativação e solicita outra execução vinte segundos após a ativação anterior. AccuracySec=1s permite uma pequena janela de agendamento; a máquina pode acrescentar atraso. É um ensaio curto, não uma programação diária de produção. Um horário diário de relógio poderia usar OnCalendar=*-*-* 23:00:00 no lugar dessas duas diretivas relativas, escolhendo deliberadamente o fuso do servidor. Aqui mantemos o intervalo curto para observar execuções reais.
sudo tee /etc/systemd/system/d10-sales.timer <<'UNIT'
[Unit]
Description=Daymark short training schedule
[Timer]
OnActiveSec=5s
OnUnitActiveSec=20s
AccuracySec=1s
[Install]
WantedBy=timers.target
UNIT
daemon-reload relê as definições das unidades. enable --now conecta o timer a timers.target para futuras inicializações e o inicia agora. Inicia o timer, não uma exportação manual:
sudo systemctl daemon-reload
sudo systemctl enable --now d10-sales.timer
sleep 50 espera sem executar a tarefa. Não inicie manualmente o serviço nem use um laço de shell no lugar do timer.
sleep 50
list-timers mostra acionamentos reais LAST e NEXT. --no-pager imprime diretamente em vez de abrir um visualizador com rolagem:
systemctl list-timers d10-sales.timer --no-pager
O journal é o registro real de eventos do systemd. -u seleciona esta unidade e -n 20 limita a saída. Deve conter pelo menos duas execuções completas, com uid=... cwd=/srv/daymark-sales, um hash do relatório e conclusão bem-sucedida:
sudo journalctl -u d10-sales.service -n 20 --no-pager
Compare o uid numérico com id daymark-report. inactive (dead) após um oneshot bem-sucedido é normal; um timer ativo solicita execuções futuras. show -p seleciona propriedades específicas do estado:
systemctl show d10-sales.service -p User -p WorkingDirectory -p Result -p ExecMainStatus --no-pager
Espere User=daymark-report, o diretório correto, Result=success e ExecMainStatus=0. Se não houver acionamento, leia systemctl status d10-sales.timer --no-pager; corrija apenas esses arquivos, repita daemon-reload e reinicie somente d10-sales.timer. restart para e inicia esse timer para aplicar suas alterações. Espere novamente e examine o journal. Para CHDIR, confira WorkingDirectory; diante de Permission denied, examine a propriedade da entrada e do diretório de relatórios sem ampliar permissões.
Volte para Daymark, recarregue Reports e baixe o novo CSV. Seu total é TOTAL,11,3450. Abra Records novamente e volte ao início; as páginas normais do negócio continuam disponíveis.
Recuperar na próxima execução agendada
Nesta etapa, você observará falhas agendadas reais, preservará o relatório anterior e publicará um novo fechamento após a recuperação. Comece em Workstation. Trabalhe apenas nas unidades D10 e na entrada deste exercício; nunca pare serviços não relacionados.
Primeiro crie um erro de diretório de trabalho. sed -i edita o arquivo indicado no lugar; s|old|new| substitui texto correspondente. É uma falha intencional:
sudo sed -i 's|WorkingDirectory=/srv/daymark-sales|WorkingDirectory=/tmp|' /etc/systemd/system/d10-sales.service
sudo systemctl daemon-reload
sleep 30
sudo journalctl -u d10-sales.service -n 15 --no-pager
O processo continua executando com a conta de relatórios, mas orders.csv é resolvido em /tmp e falha com Export failed: ... No such file .... Se o próprio diretório de trabalho não existisse, ocorreria CHDIR antes de executar o script. daemon-reload atualiza definições, não executa a tarefa. O timer causou essa tentativa com falha.
cat reports/sales.csv
O relatório ainda deve terminar com TOTAL,11,3450. Em Daymark, recarregue Reports e baixe para confirmar que os mesmos bytes continuam utilizáveis. Volte para Workstation e corrija o diretório:
sudo sed -i 's|WorkingDirectory=/tmp|WorkingDirectory=/srv/daymark-sales|' /etc/systemd/system/d10-sales.service
sudo systemctl daemon-reload
Agora exercite uma falha de entrada. cp copia um fixture malformado preparado somente sobre orders.csv; o calculador deve retornar status não zero e o script deve manter o último relatório intacto:
cp fixtures/broken.csv orders.csv
sleep 30
sudo journalctl -u d10-sales.service -n 15 --no-pager
Espere a falha intencional de número inválido. show revela o último status real de saída, independentemente do sucesso do comando de visualização do journal:
systemctl show d10-sales.service -p Result -p ExecMainStatus --no-pager
Espere Result=exit-code e ExecMainStatus=1. Confirme que o relatório anterior permanece:
cat reports/sales.csv
Restaure um fechamento válido novo com dois Tea adicionais. A recuperação deve atualizar o total para 13 unidades e 3950 centavos no próximo acionamento:
cp fixtures/next.csv orders.csv
sleep 30
sudo journalctl -u d10-sales.service -n 15 --no-pager
cat reports/sales.csv
Espere Tea,5,1250 e TOTAL,13,3950, com uma publicação real posterior no journal. Se continuar antigo, leia o erro mais recente, corrija diretório, nome da entrada ou script e espere outro evento do timer. Não substitua o CSV manualmente nem inicie o serviço manualmente. O oneshot que falhou pode executar de novo com este timer.
Em Daymark, recarregue Records e Reports, baixe novamente e compare a origem alterada com TOTAL,13,3950. Mantenha o timer ativo para avaliação. Este exercício não testa recuperação após reinicialização, política de fuso, concorrência entre máquinas ou contabilização de dias perdidos.
Resumo
Você praticou publicação completa de CSV, estados de falha significativos e recuperação. Um relatório agendado só é útil quando sua identidade real de execução, acionamento e totais do negócio concordam. Este exercício de instância única usa dados fictícios e um agendamento curto de treinamento; não é uma plataforma completa de relatórios de produção.
