Dietpi: Problema com cron e backup automático (de v6.10-6.11)?

@eljotx
Obrigado pelo seu relatório.

G_USER_INPUT=0 deve ser detectado automaticamente nas execuções do cron, portanto, não é necessário atribuir. Mas se você quiser que tenha efeito, você precisa exportá-lo, o que obviamente vale a pena tentar:
export G_USER_INPUT=0

Em execuções não interativas, o script fecharia se (perto de) espaço livre insuficiente fosse detectado na unidade de destino: https://github.com/Fourdee/DietPi/blob/master/dietpi/dietpi-backup#L456
Mas você diz, a execução manual funciona bem? Em caso de espaço livre insuficiente, você verá o prompt de whiptail, que lhe dará a opção de ignorar ou sair.

Sobre as entradas de log, alguns códigos de cores crípticos + checking for elevation root access são esperados. Tentar:
cat /mnt/rpi/backup.log
para ter os códigos de cores ativos e, portanto, o log formatado. Forneça também essa saída aqui, para que possamos verificar em que estágio o problema ocorreu.

Script funcionando bem quando eu o executo manualmente.

Estranho.

Tente executar o cron job e colar os resultados do registro /mnt/rpi/backup.log

NB: dietpi-backup gera automaticamente rsync para o arquivo de log /var/log/dietpi-backup.log , você também pode usar isso.

Então, tento executar o cron job sem G_USER_INPUT = 0 (removi isso do script) e ...

Meu arquivo de log de backup de /mnt/rpi/backup.log
[90m[[0m[33m......[90m][0m Checking for (elevated) root access[0m

dietpi-backup.log está vazio

Não vi nenhum processo ativo depois que o cron foi iniciado.

Portanto, adicionei ao teste outro script, para ver a saída no arquivo após o início do cron:

#!/bin/sh

echo 'Cron works!' > /mnt/rpi/cronworks.log

mas este script não foi iniciado - não há arquivo "cronworks.log" em / mnt / rpi /
é estranho porque há um arquivo de saída (backup.log) do meu script com backup (do primeiro meu post), mas não deste simples

@eljotx
Ok, parece haver pelo menos um erro com o cron. Observe que o cron inicia os scripts por meio de run-parts /etc/cron.X/script e existem algumas regras, por exemplo, os scripts devem ser de propriedade do root (AFAIK) e mais certeza de que os scripts não podem ter terminações de arquivo. Isso significa que /etc/cron.daily/script.sh será ignorado, o nome deve ser /etc/cron.daily/script .

Também não deve ser necessário, mas tente usar #!/bin/bash como shebang ao usar com scripts DietPi. Esses próprios têm #!/bin/bash , mas para evitar falhas, tente usá-lo também no script cron.

O script sempre teve um nome "backup" (sem .sh), eu mudo "#! / Bin / sh" para "#! / Bin / bash" no script também, e este script pertence ao root. Meu script de "teste" do último post está funcionando agora também.

Tentei de tudo, mas ainda não está funcionando. Eu mudo o script para imprimir no arquivo de log após terminar um trabalho e vi que o script é iniciado, mas o backup não é iniciado ou concluído (dietpi-backup.log está vazio), porque não posso ir para o próximo trabalho como tar, rclone etc. .E também depois de executar o cron eu vi o processo / usr / sbin / cron -f funcionando e -bash - é normal?

O script ainda está funcionando se eu executá-lo manualmente - mas quando o backup terminar, devo clicar em OK e Cancelar (telas de whiptail) e, depois disso, os próximos trabalhos são iniciados.

Acho que o problema está em usar dietpi-backup para backup automático iniciado pelo cron. Funcionou na versão 6.9, mas não funcionou depois de reescrever o dietpi-backup.

@eljotx
Então, novamente, apenas para ter certeza:

• Se você executar manualmente /DietPi/dietpi/dietpi-backup 1 é executado com sucesso?
• Se você executar G_USER_INPUTS=0 /DietPi/dietpi/dietpi-backup 1 também funcionará sem nenhum erro, mostrando algo como:
  

root@VM-Jessie:~# G_USER_INPUTS=0 /DietPi/dietpi/dietpi-backup 1
[  OK  ] Root access verified.
[  OK  ] DietPi-Drive_Manager | RootFS R/W access verified.

[  OK  ] DietPi-Backup | Checking for pre-req APT packages: rsync
[ INFO ] DietPi-Backup | Flagged for installation: rsync
[  OK  ] DietPi-Backup | APT installation for: rsync, please wait...
Selecting previously unselected package rsync.
(Reading database ... 36227 files and directories currently installed.)
Preparing to unpack .../rsync_3.1.1-3+deb8u1_amd64.deb ...
Unpacking rsync (3.1.1-3+deb8u1) ...
Processing triggers for systemd (215-17+deb8u7) ...
Setting up rsync (3.1.1-3+deb8u1) ...
Processing triggers for systemd (215-17+deb8u7) ...

[  OK  ] DietPi-Backup | G_AGI: rsync

 DietPi-Backup
─────────────────────────────────────────────────────
 Mode: Backup

[  OK  ] DietPi-Backup | DietPi-Userdata validation: /mnt/dietpi_userdata
[ SUB1 ] DietPi-Services > stop
[  OK  ] DietPi-Services | occ maintenance:mode --on
[  OK  ] DietPi-Services | stop : cron
[  OK  ] DietPi-Services | stop : sonarr
[  OK  ] DietPi-Services | stop : lighttpd
[  OK  ] DietPi-Services | stop : php5-fpm
[  OK  ] DietPi-Services | stop : mysql
[ SUB1 ] DietPi-Services > stop
[  OK  ] DietPi-Services | stop : cron
[  OK  ] DietPi-Services | stop : sonarr
[  OK  ] DietPi-Services | stop : lighttpd
[  OK  ] DietPi-Services | stop : php5-fpm
[  OK  ] DietPi-Services | stop : mysql
[ INFO ] DietPi-Backup | Backing up to: /mnt/dietpi-backup
[  OK  ] DietPi-Backup | Free space check: path=/mnt/dietpi-backup/data | available=5695 MB | required=1861 MB
[  OK  ] DietPi-Backup | rsync -aH --delete --delete-excluded --exclude-from=/tmp/.dietpi-backup_filter_inc_exc -v --log-file=/var/log/dietpi-backup.log / /mnt/dietpi-backup/data/
[ INFO ] DietPi-Backup | Backup Completed:

Backup was saved to:
- /mnt/dietpi-backup
- Log file: /var/log/dietpi-backup.log
[ SUB1 ] DietPi-Services > start
[  OK  ] DietPi-Services | start : mysql
[  OK  ] DietPi-Services | start : php5-fpm
[  OK  ] DietPi-Services | start : lighttpd
[  OK  ] DietPi-Services | start : sonarr
[  OK  ] DietPi-Services | start : cron
[ SUB2 ] DietPi-Process_tool > Apply
[  OK  ] DietPi-Process_tool | Completed
[  OK  ] DietPi-Services | occ maintenance:mode --off

• Executando a linha de comando exata do script

/DietPi/dietpi/dietpi-backup 1 > /mnt/rpi/backup.log && tar zcfv /mnt/rpi/backup.tar.gz /mnt/backup/dietpi-backup/ >> /mnt/rpi/backup.log && rclone copy /mnt/rpi/backup.tar.gz dysk: -L >> /mnt/rpi/backup.log && rm -r /mnt/rpi/backup.tar.gz >> /mnt/rpi/backup.log && reboot

funciona bem, mostrando que tudo foi executado e finalizado em /mnt/rpi/backup.log ?

• run-parts --test /etc/cron.daily lista seu script (se for diário, caso contrário, ajuste)
• /usr/sbin/cron -f + -bash é esperado sim, já que inicia um ambiente de bash devido a #!/bin/bash .

Se tudo o que foi dito acima for verdade, você pode tentar iniciar manualmente o run-parts e ver se ele executa como esperado:

• Mova / copie o script para uma pasta separada, por exemplo, ~/testdir/backup
• Então run-parts ~/testdir

Testei como você mostra e em todas as suas dúvidas: sim, tudo funcionando quando inicio manualmente.
Eu testei com o comando run-parts, mas ainda está funcionando - quando faço manualmente.

Meu script é listado após o uso run-parts --test /etc/cron.daily

Se eu adicionar G_USER_INPUTS = 0 e iniciar o script manualmente, devo ver as telas (whiptail) com informações sobre o log, etc.? Porque eu vejo isso sempre.

@eljotx
G_USER_INPUTS=0 apenas desativa a exibição dos menus de rabo de cavalo. As informações são mostradas apenas como mensagens do terminal e as perguntas são respondidas como "não" (cancelar em caso de verificação de espaço livre insuficiente, sem visualização de log).

Para forçá-lo para o script, você precisa exportá-lo antes de executar o script:

#!/bin/bash
export G_USER_INPUTS=0
/DietPi/dietpi/dietpi-backup 1

ou mais fácil, apenas entregue diretamente: G_USER_INPUTS=0 /DietPi/dietpi/dietpi-backup 1

Acabei de reconhecer que você usou G_USER_INPUT=0 acima sem S , deve ser G_USER_INPUTS=0 com S .

Mas se a variável não for exportada, os scripts irão determinar se as entradas do usuário podem ser feitas ou não. Nas execuções da unidade cron e, por exemplo, do systemd, todos os scripts DietPi devem determinar e atribuir automaticamente G_USER_INPUTS=0 .
Você pode verificar se nosso método funciona, adicionando ao início de seu cron job (ou um trabalho de teste):
[[ -t 0 ]] && echo 'This environments allows user inputs' > /mnt/rpi/inputs.log || echo 'This environment does not allow user inputs' > /mnt/rpi/inputs.log
Ao executar o script manualmente, ele deve dizer que as entradas do usuário são permitidas (menus whiptail aparecem), se for iniciado via cron, então não deveria, e nenhum menu whiptail deve fazer o script travar.

Primeiro eu testo G_USER_INPUTS=0 e se eu iniciar o script manualmente, registro:
This environments allows user inputs
else if start by cron:
This environment does not allow user inputs

Em seguida, tento mudar meu script para este:

#!/bin/bash
export G_USER_INPUTS=0
date > /mnt/rpi/backup.log && /DietPi/dietpi/dietpi-backup 1 && (echo "Backup: DONE. " >> /mnt/rpi/backup.log && tar zcfv /mnt/rpi/backup.tar.gz /mnt/backup/dietpi-backup/ && echo "Tar backup: DONE. " >> /mnt/rpi/backup.log && rclone copy /mnt/rpi/backup.tar.gz dysk: && echo "Copy to GDrive: DONE. " >> /mnt/rpi/backup.log && rm -r /mnt/rpi/backup.tar.gz && echo "Remove tar: DONE." >> /mnt/rpi/backup.log && reboot) || echo "Backup failed!" >> /mnt/rpi/backup.log

e dietpi-backup.log ainda está vazio, mas backup.log:

quando o cron for iniciado e iniciar automaticamente este script:

pon, 9 lip 2018, 18:54:01 CEST
Backup failed!

quando iniciei o script manualmente:

pon, 9 lip 2018, 18:58:40 CEST
Backup: DONE.
Tar backup: DONE.
Copy to GDrive: DONE.
Remove tar: DONE.

É muito chato ... a seguir, meu script só tem:

#!/bin/bash
export G_USER_INPUTS=0
/DietPi/dietpi/dietpi-backup 1

e ainda não funciona se este script for iniciado pelo cron.

O problema ainda é com o dietpi-backup iniciado pelo cron a partir da v6.10. Eu acho que é o problema com as mudanças que você fez na v6.10 no script dietpi-backup.

dietpi-backup.log ainda está vazio

@eljotx
Obrigado pelo seu esforço de teste.
Vou passar por nossa mudança. Não tenho ideia até agora. Pelo menos de acordo com seus testes, o script na verdade não está travando (whiptail / G_USER_INPUTS não é o problema), mas falhando.

Fiz alguns testes:

[......] Checking for (elevated) root access

Depois de comentar a verificação do usuário root, em dietpi-backup , executá-la via cron leva a:
[FAILED] RootFS is currently Read Only, unable to continue.
Mas:

root@VM-Jessie:~# G_CHECK_ROOTFS_RW
[  OK  ] Root access verified.
[  OK  ] DietPi-Drive_Manager | RootFS R/W access verified.

@eljotx

tput é o problema:
tput: No value for $TERM and no -T specified

• Interessante, como chamamos isso na v6.9 também 🤔.

Correção: https://github.com/Fourdee/DietPi/commit/82ac7b32d32dca9db4fdb824c7ead80174844090

Este patch também corrige outro problema: "run_ntpd 1" executado pelo cron diariamente ou de hora em hora não sincroniza a hora (o carimbo de data / hora de / var / lib / systemd / clock não muda).

@kmakisara
Jep você está certo, isso faz sentido.
Apenas para evitar a edição manual do script para aplicar a correção, todos com o mesmo problema devem fazer: wget https://raw.githubusercontent.com/Fourdee/DietPi/82ac7b32d32dca9db4fdb824c7ead80174844090/dietpi/func/dietpi-globals -O /DietPi/dietpi/func/dietpi-globals

Acho que algumas das nossas questões abertas estão relacionadas a isso. Se run_ntpd dentro de cron.hourly falhar, dietpi-logclear também não será chamado depois, fazendo com que / var / log encha: https://github.com/Fourdee/DietPi/issues/ 1920

Só estou me perguntando por que esse problema apareceu primeiro com a v6.10 +, já que já usávamos tput em nossos cron jobs.
Talvez alguém consiga encontrar a mudança que causou os problemas, para que saibamos como cuidar melhor no futuro:

• Chamando a notificação de processo animado v6.9: https://github.com/Fourdee/DietPi/blob/7b682286e72ef339518d110892a54e7ce405b648/dietpi/func/dietpi-globals#L301 -L315
• Alterações feitas com v6.10: https://github.com/Fourdee/DietPi/pull/1867/files
• tput cuu e tput cols são chamados em ambos os casos, bem como tput ed em todas as outras notificações DietPi ao limpar a animação de processamento.
• Talvez não tenham sido as mudanças nas notificações que causaram o problema, mas os erros de manipulação do cron (ou tput) de forma diferente após determinada atualização.

Testes adicionais sobre isso:

root@VM-Stretch:/tmp# cat /etc/cron.minutely/test
#!/bin/bash

echo "$TERM" &> /tmp/cron.test
tput ed &>> /tmp/cron.test
echo 'finish' &>> /tmp/cron.test
root@VM-Stretch:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified

• $TERM no cron está definido como dumb
• tput afirma que não há valor para a variável, mesmo que seja, embora inválido.

root@VM-Stretch:/tmp# TERM='dumb' tput cols
237
root@VM-Stretch:/tmp# export TERM='dumb' tput cols
root@VM-Stretch:/tmp# export TERM='dumb' tput cols && echo continue
continue

• Como $ TERM inválido não leva a nenhum erro (apenas leva a nenhuma saída de tput), o erro de tput do cron parece estar relacionado à falta de -T , [[ -t 0 ]] resulta em falso. Talvez isso também tenha se comportado de maneira diferente antes. Última atualização de ncurses-bin APT em 15/02/2018: http://ftp.de.debian.org/debian/pool/main/n/ncurses/

• Já tivemos problemas com terminais não interativos / inválidos, portanto, saia agora dos scripts dietpi- *, se $ TERM vazio ou ' unknown ' for encontrado: https://github.com/Fourdee/DietPi/blob/ testando / dietpi / func / dietpi-globals # L30 -L35

• Um lance inconsistente, uma vez que podemos querer permitir execuções não interativas (também sem nenhum terminal conectado), mas precisamos tomar cuidado ao chamar tput respectivamente outros comandos que precisam de um terminal válido.

Teste em v6.9:

root<strong i="6">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
finish

• Erro aparece, mas o script é retomado.

A atualização do APT não contém cron e / ou ncurses (reduzindo por pacotes não relacionados testados):

• Mesmo depois de apt-get dist-upgrade e reinicializar, o cron não para a execução após o erro tput:

root<strong i="15">@DietPi</strong>:/tmp# cat /etc/cron.minutely/test
#!/bin/bash

echo "$TERM" &> /tmp/cron.test
[[ -t 0 ]] && echo 'interactive' &>> /tmp/cron.test
tput ed &>> /tmp/cron.test
echo 'finish' &>> /tmp/cron.test
root<strong i="16">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
finish

• dietpi-update para mestre v6.11: Muito estranho, ainda sem problemas ...

root<strong i="22">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
finish

• Adicionando execução de backup dietpi:

root<strong i="27">@DietPi</strong>:/tmp# cat /etc/cron.minutely/test
#!/bin/bash

echo "$TERM" &> /tmp/cron.test
[[ -t 0 ]] && echo 'interactive' &>> /tmp/cron.test
tput ed &>> /tmp/cron.test
/DietPi/dietpi/dietpi-backup 1 &>> /tmp/cron.test
echo 'finish' &>> /tmp/cron.test
root<strong i="28">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
[......] Checking for (elevated) root accesstput: No value for $TERM and no -T specified
/DietPi/dietpi/func/dietpi-globals: line 266: ( 38 + 6 ) /  : syntax error: operand expected (error token is "/  ")
finish

• O script falha, mas o cron job continua. Teste com dietpi-globals v6.9:

root<strong i="34">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
         Checking for (elevated) root accesstput: No value for $TERM and no -T specified
/DietPi/dietpi/func/dietpi-globals: line 308: ((: lines=(38+6)/ : syntax error: operand expected (error token is "/ ")
tput: No value for $TERM and no -T specified
[  OK  ] Root access verified.
         DietPi-Run_ntpd | systemctl restart systemd-timesyncdtput: No value for $TERM and no -T specified
/DietPi/dietpi/func/dietpi-globals: line 308: ((: lines=(38+6)/ : syntax error: operand expected (error token is "/ ")
[..    ] tput: No value for $TERM and no -T specified
[  OK  ] DietPi-Run_ntpd | systemctl restart systemd-timesyncd
[ INFO ] DietPi-Run_ntpd | NTPD: Waiting for completion of systemd-timesyncd (1/60)
[  OK  ] DietPi-Run_ntpd | NTPD: systemd-timesyncd synced
[  OK  ] NTPD: time sync | Completed
finish

- Ok, está relacionado às mudanças globais, mas como tput falhou e falhou, por que nossos scripts saem agora e não saem na v6.9?

Alteração relacionada identificada: https://github.com/Fourdee/DietPi/blob/master/dietpi/func/dietpi-globals#L266
local lines=$(( (${#input_string}+6)/$(tput cols) )) leva à saída do script inteiro, enquanto (anterior)

local lines
(( lines=(${#input_string}+6)/$(tput cols) ))

mostrou o erro, mas permitiu que o script continuasse (veja acima).

Fix https://github.com/Fourdee/DietPi/commit/82ac7b32d32dca9db4fdb824c7ead80174844090 funciona e também é a solução mais limpa, já que tput será completamente ignorado em shells não interativos. Mas, para evitar falhas, devemos voltar ao método anterior para declarar a variável primeiro e, em seguida, atribuir o valor depois dentro do ambiente aritmético: Commit done https://github.com/Fourdee/DietPi/commit/0f18aa4dc0af8ab910a0173dce8849d5b53c30b0

@eljotx @kmakisara
Para limpar uma licitação, abri um novo problema, tente aplicar a correção mencionada lá e informe, se isso resolver todos os problemas: https://github.com/Fourdee/DietPi/issues/1923

Vou encerrar esta questão em favor do novo.

Eu poderia ssh com sucesso em meu v6.13, mas ele travaria logo depois.

O comando "tput cols" estava gerando tput: terminal desconhecido "rxvt-256color" , resultando em um valor vazio na linha 328 de dietpi-login, fazendo com que ele travasse para sempre após ter lido o banco de dados com sucesso na inicialização.

Exportar TERM = xterm, um hack feio, parecia ter corrigido o script de login e agora pode começar a instalação.

Se esta for a seção errada, seja paciente, pois eu realmente não sei como usar os problemas do github; Eu encontrei este tópico após horas de busca inútil no Google por um erro, se você movê-lo, talvez deixe um resto sobre erros rxvt-256color, caso alguém tenha o mesmo problema.

Cumprimentos!

@wuhei

Oi,

Obrigado pelo relatório e solução 👍

Qual cliente SSH você está executando?

@Fourdee
Eu estava abrindo uma edição separada para isso. Identificou o problema: https://github.com/Fourdee/DietPi/issues/2034

@wuhei
Depois de entrar no SSH, tente: export TERM='xterm-256color' €: Ah, isso é basicamente o que você já descobriu 😄.
Se funcionar, você pode adicionar um script a /etc/profile.d/ que contenha algo como:
[[ $SSH_TTY ]] && [[ $TERM =~ 256 ]] && export TERM='xterm-256color'

• Em palavras: se esta for uma conexão SSH, e o cliente SSH passou um terminal colorido de 256 bits, ajuste-o para xterm-256color , que é compatível com DietPi.

Uma alternativa seria instalar um pacote que contenha mais definições de terminal: G_AGI ncurses-term

@Fourdee OpenSSH_7.7p1, OpenSSL 1.1.0h no Arch Linux

@MichaIng obrigado, fico feliz por ter ajudado por acaso!

Lembre-se de que sou um administrador de sistema incorreto e, seguindo este artigo de Tom Ryder , descobri que tinha uma configuração de "declaração" de terminal muito mal configurada.

No final, o que resolveu o problema para mim foi

• exportando o $ TERM correto em /root/.bashrc
• copiando a entrada correta do terminfo da minha instalação do arch na pasta /root/.terminfo do pi

Não consegui fazer o scp do arquivo terminfo para o meu pi, porque o scp não está instalado (talvez considere instalá-lo junto com o servidor dropbear?), Então fiz o upload para um servidor que possuo e acabei de retirá-lo do pi.

Que bom que pude ajudar, gritos e desculpe novamente pela bagunça - rock on!

@wuhei
Jep, definir $ TERM em /root/.bashrc funciona bem, adicionando-o a /etc/profile[.d/] resolve todo o sistema para todos os usuários, que é uma solução que escolheríamos com o DietPi.

O artigo que você linkou é muito bom, explicando muito bem tudo e as possibilidades 👍. Basicamente, você instalou o tipo de terminal necessário manualmente. O artigo também menciona o pacote ncurses-term como uma opção para instalar uma ampla gama de definições de terminal. Mas para manter o DietPi magro, não estou muito interessado em pré-instalar este pacote para esses casos raros. Em vez disso, melhor, vá com a solução bashrc / profile; Também é possível simplesmente verificar o suporte do terminal antes de aplicar a correção no login SSH.

Para testar com o cliente PuTTY: PuTTY> Connection > Data > Terminal-type string

Sobre a instalação do SCP: Existem vários outros protocolos de transferência de arquivos, FTP, SFTP ou unidades de rede NFS, SMB, para transferir arquivos. Eu não faria a pré-instalação, mas deixaria a escolha do usuário como obter os arquivos do cliente para o servidor. Stick USB, drive externo também é possível ou simplesmente copie e cole no terminal SSH no caso. Mas de qualquer maneira, como solução geral, eu escolheria uma das duas maneiras mencionadas acima.