Dietpi: ¿Problema con cron y la copia de seguridad automática (desde v6.10-6.11)?

@eljotx
Gracias por tu informe.

G_USER_INPUT=0 debería detectarse automáticamente en ejecuciones cron, por lo que no es necesario asignarlo. Pero si desea que tenga efecto, debe exportarlo, lo que, por supuesto, vale la pena probar:
export G_USER_INPUT=0

En ejecuciones no interactivas, la secuencia de comandos se cerraría si se detectara (cerca de) espacio libre insuficiente en la unidad de destino: https://github.com/Fourdee/DietPi/blob/master/dietpi/dietpi-backup#L456
¿Pero dices que la ejecución manual funciona bien? En caso de que no haya suficiente espacio libre, verá un mensaje de cola de látigo que le da la opción de ignorar o salir.

Acerca de las entradas del registro, se esperan algunos códigos de color crípticos + checking for elevation root access . Tratar:
cat /mnt/rpi/backup.log
para tener los códigos de color activos y por lo tanto formateado el registro. También proporcione este resultado aquí, para que podamos verificar en qué etapa ocurrió el problema.

El script funciona bien cuando lo ejecuto manualmente.

Extraño.

Intente ejecutar el trabajo cron y pegue los resultados del registro /mnt/rpi/backup.log

NB: dietpi-backup genera automáticamente rsync en el archivo de registro /var/log/dietpi-backup.log , también puede usarlo.

Entonces, intento ejecutar el trabajo cron sin G_USER_INPUT = 0 (eliminé esto del script) y ...

Mi archivo de registro de respaldo de /mnt/rpi/backup.log
[90m[[0m[33m......[90m][0m Checking for (elevated) root access[0m

dietpi-backup.log está vacío

No vi ningún proceso activo después del tiempo en que se inició cron.

Entonces, agregué a probar otro script, para ver la salida en el archivo después del inicio cron:

#!/bin/sh

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

pero esta secuencia de comandos no se inició, no hay ningún archivo "cronworks.log" en / mnt / rpi /
es extraño porque hay un archivo de salida (backup.log) de mi script con copia de seguridad (desde el primero de mi publicación), pero no de este simple

@eljotx
De acuerdo, parece haber al menos un error con cron. Tenga en cuenta que cron inicia los scripts a través de run-parts /etc/cron.X/script y hay algunas reglas, por ejemplo, los scripts deben ser propiedad de root (AFAIK) y más seguro que los scripts no pueden tener terminaciones de archivo. Eso significa que se omitirá /etc/cron.daily/script.sh , el nombre debe ser /etc/cron.daily/script lugar.

Además, no debería ser necesario, pero intente usar #!/bin/bash como shebang cuando lo use con los scripts DietPi. Esos mismos tienen #!/bin/bash , pero para estar seguro, intente usarlo también dentro del script cron.

El script siempre tuvo un nombre "copia de seguridad" (sin .sh), yo cambio "#! / Bin / sh" a "#! / Bin / bash" en el script también, y este script ha sido propiedad de root. Mi script de "prueba" de la última publicación ahora también funciona.

Intenté todo, pero todavía no funciona. Cambio el script para imprimir en el archivo de registro después de terminar un trabajo y vi que el script se inicia, pero la copia de seguridad no comienza ni termina (dietpi-backup.log está vacío), porque no puedo ir al siguiente trabajo como tar, rclone, etc. Y también después de ejecutar cron vi el proceso / usr / sbin / cron -f trabajando y -bash - ¿es normal?

El script sigue funcionando si lo ejecuto manualmente, pero cuando finaliza la copia de seguridad, debo hacer clic en Aceptar y Cancelar (pantallas de cola de látigo), y después de eso, comienzan los siguientes trabajos.

Creo que el problema es el uso de dietpi-backup para la copia de seguridad automática iniciada por cron. Funcionó en la versión 6.9, pero no funcionó después de reescribir dietpi-backup.

@eljotx
Así que de nuevo, solo para estar seguro:

• Si ejecuta manualmente /DietPi/dietpi/dietpi-backup 1 se ejecuta correctamente?
• Si ejecuta G_USER_INPUTS=0 /DietPi/dietpi/dietpi-backup 1 funciona sin ningún error, 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

• Ejecutando la fila de comando exacta desde el 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 también, mostrando todo se ejecutó y terminó en /mnt/rpi/backup.log ?

• run-parts --test /etc/cron.daily enumera su secuencia de comandos (si es diaria, de lo contrario, ajuste)
• Se espera /usr/sbin/cron -f + -bash sí, ya que inicia un entorno bash debido a #!/bin/bash .

Si todo lo anterior es cierto, entonces podría intentar iniciar manualmente run-parts y ver si se ejecuta como se esperaba:

• Mueva / copie el script en una carpeta separada, por ejemplo, ~/testdir/backup
• Entonces run-parts ~/testdir

Probé como muestra y en cada una de sus preguntas: sí, todo funciona cuando lo inicio manualmente.
Lo probé con el comando run-parts, pero todavía funciona, cuando lo hago manualmente.

Mi secuencia de comandos aparece después de usar run-parts --test /etc/cron.daily

Si agrego G_USER_INPUTS = 0 e inicio el script manualmente, ¿debería ver las pantallas (cola de látigo) con información sobre el registro, etc.? Porque lo veo siempre.

@eljotx
G_USER_INPUTS=0 simplemente desactiva los menús de cola de látigo para mostrar. La información solo se muestra como mensajes de terminal y las preguntas se responden como "no" (cancele en caso de verificación de espacio libre insuficiente, sin vista de registro).

Para forzarlo para el script, necesita exportarlo antes de ejecutar el script:

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

o más fácil, simplemente entrégalo directamente: G_USER_INPUTS=0 /DietPi/dietpi/dietpi-backup 1

Acabo de reconocer que usaste G_USER_INPUT=0 arriba sin S , debe ser G_USER_INPUTS=0 con S .

Pero si no se exporta la variable, los scripts determinarán si se pueden realizar entradas del usuario o no. Dentro de las ejecuciones de unidades cron y, por ejemplo, systemd, todos los scripts DietPi deben determinar y asignar automáticamente G_USER_INPUTS=0 .
Puede verificar que nuestro método funciona agregando al inicio de su trabajo cron (o un trabajo de prueba):
[[ -t 0 ]] && echo 'This environments allows user inputs' > /mnt/rpi/inputs.log || echo 'This environment does not allow user inputs' > /mnt/rpi/inputs.log
Cuando se ejecuta el script manualmente, debería decir que las entradas del usuario están permitidas (aparecen los menús de cola flexible), si se inicia a través de cron, entonces no debería hacerlo, y ningún menú de cola flexible debería hacer que el script se cuelgue.

Primero pruebo G_USER_INPUTS=0 y si inicio el script manualmente, registro:
This environments allows user inputs
de lo contrario, si comienza por cron:
This environment does not allow user inputs

A continuación, trato de cambiar mi script a esto:

#!/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

y dietpi-backup.log todavía está vacío, pero backup.log:

cuando cron se inició e inicia automáticamente este script:

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

cuando comencé el script manualmente:

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

Es muy molesto ... a continuación, mi script solo tiene:

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

y aún no funciona si este script lo inicia cron.

El problema sigue siendo dietpi-backup iniciado por cron desde v6.10. Creo que es un problema con los cambios que hizo en v6.10 en el script dietpi-backup.

dietpi-backup.log todavía está vacío

@eljotx
Gracias por tu esfuerzo de prueba.
Revisaré nuestro cambiado. No tengo ni idea hasta ahora. Al menos de acuerdo con sus pruebas, el script en realidad no se cuelga (whiptail / G_USER_INPUTS no es el problema), pero falla.

Hizo algunas pruebas propias:

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

Después de comentar la verificación del usuario root, dentro de dietpi-backup , ejecutarlo a través de cron conduce a:
[FAILED] RootFS is currently Read Only, unable to continue.
Pero:

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

@eljotx

tput es el problema:
tput: No value for $TERM and no -T specified

• Interesante, como también lo llamamos con v6.9 🤔.

Solución: https://github.com/Fourdee/DietPi/commit/82ac7b32d32dca9db4fdb824c7ead80174844090

Este parche también soluciona otro problema: "run_ntpd 1" ejecutado por cron diariamente o cada hora no sincroniza la hora (la marca de tiempo de / var / lib / systemd / clock no cambia).

@kmakisara
Jep, tienes razón, esto tiene sentido.
Solo para evitar la edición manual del script para aplicar la corrección, todos con el mismo problema deberían hacerlo: wget https://raw.githubusercontent.com/Fourdee/DietPi/82ac7b32d32dca9db4fdb824c7ead80174844090/dietpi/func/dietpi-globals -O /DietPi/dietpi/func/dietpi-globals

Creo que algunos de nuestros problemas abiertos están relacionados con esto. Si run_ntpd dentro de cron.hourly falla, dietpi-logclear tampoco se llamará después, lo que llevará a que / var / log se llene: https://github.com/Fourdee/DietPi/issues/ 1920

Me pregunto por qué este problema apareció primero con v6.10 +, ya que usamos tput antes en nuestros trabajos cron.
Tal vez alguien pueda encontrar el cambio que causó los problemas, para que sepamos cómo cuidarnos mejor en el futuro:

• Notificación de proceso animada v6.9: https://github.com/Fourdee/DietPi/blob/7b682286e72ef339518d110892a54e7ce405b648/dietpi/func/dietpi-globals#L301 -L315
• Cambios realizados con v6.10: https://github.com/Fourdee/DietPi/pull/1867/files
• tput cuu y tput cols se llaman en ambos casos, así como tput ed en cada otra notificación de DietPi al borrar la animación de procesamiento.
• Tal vez no fueron los cambios en las notificaciones lo que causó el problema, sino los errores de manejo de cron (o tput) de manera diferente después de cierta actualización.

Más pruebas sobre esto:

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 en cron se establece en dumb
• tput afirma que no hay valor para la variable, incluso si lo es, aunque no es vá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 un $ TERM inválido no conduce a ningún error (solo no conduce a una salida tput), el error cron tput parece estar relacionado con la falta de -T , [[ -t 0 ]] da como resultado falso. Quizás también esto se comportó de manera diferente antes. Última actualización de ncurses-bin APT en 2018-02-15: http://ftp.de.debian.org/debian/pool/main/n/ncurses/

• Ya tuvimos problemas con terminales no interactivos / inválidos, por lo tanto, ahora salga de los scripts dietpi- *, si se encuentra $ TERM o ' unknown ' vacío: https://github.com/Fourdee/DietPi/blob/ pruebas / dietpi / func / dietpi-globals # L30 -L35

• Una oferta inconsistente, ya que podríamos querer permitir ejecuciones no interactivas (también sin ningún terminal adjunto), pero debemos tener cuidado de llamar tput respectivamente a otros comandos que necesitan un terminal válido.

Prueba en v6.9:

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

• Aparece el error, pero el script se reanuda.

La actualización de APT no contiene cron y / o ncurses (se reduce por paquetes probados no relacionados):

• Incluso después de apt-get dist-upgrade y reiniciar, cron no detiene la ejecución después del error 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 a v6.11 master: Muy extraño, todavía no hay problema ...

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

• Añadiendo la ejecución de dietpi-backup:

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

• La secuencia de comandos falla pero el trabajo cron continúa. Prueba con 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

- De acuerdo, ESTÁ relacionado con cambios globales, pero dado que tput falló y falla, ¿por qué nuestros scripts salen ahora y no en v6.9?

Cambio relacionado identificado: https://github.com/Fourdee/DietPi/blob/master/dietpi/func/dietpi-globals#L266
local lines=$(( (${#input_string}+6)/$(tput cols) )) conduce a la salida del script completo, mientras que (anterior)

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

mostró el error, pero permitió que la secuencia de comandos continuara (ver arriba).

Fix https://github.com/Fourdee/DietPi/commit/82ac7b32d32dca9db4fdb824c7ead80174844090 funciona y también es la solución más limpia, ya que tput se omitirá por completo dentro de shells no interactivos. Pero para estar a salvo de fallas, debemos volver al método anterior para declarar la variable primero y luego asignar un valor después dentro del entorno aritmético: Confirmación realizada https://github.com/Fourdee/DietPi/commit/0f18aa4dc0af8ab910a0173dce8849d5b53c30b0

@eljotx @kmakisara
Para limpiar una oferta, abrí un nuevo problema, intente aplicar la solución mencionada allí e informe de nuevo, si resuelve todos los problemas: https://github.com/Fourdee/DietPi/issues/1923

Cerraré este tema a favor del nuevo.

Podría ssh exitosamente en mi v6.13 pero se colgaría inmediatamente después.

El comando "tput cols" mostraba la salida tput: unknown terminal "rxvt-256color" , lo que resultaba en un valor vacío en la línea 328 de dietpi-login, por lo que se cuelga para siempre después de haber leído correctamente la base de datos en el arranque inicial.

Exportar TERM = xterm, un truco feo, parecía haber arreglado el script de inicio de sesión y ahora puede comenzar a instalarse.

Si esta es la sección incorrecta, tenga paciencia, ya que realmente no sé cómo usar los problemas de github; Encontré este hilo después de horas de búsqueda inútil en Google por un error, si lo mueve tal vez deje un resto sobre los errores de rxvt-256color, en caso de que alguien tenga mi mismo problema.

¡Atentamente!

@wuhei

Hola,

Gracias por el informe y la solución 👍

¿Qué cliente SSH está ejecutando?

@Fourdee
Estaba abriendo una edición separada para esto. Identificado el problema: https://github.com/Fourdee/DietPi/issues/2034

@wuhei
Después de iniciar sesión en SSH, intente: export TERM='xterm-256color' €: Ah, esto es básicamente lo que ya averiguó 😄.
Si esto funciona, puede agregar un script a /etc/profile.d/ que contenga algo como:
[[ $SSH_TTY ]] && [[ $TERM =~ 256 ]] && export TERM='xterm-256color'

• En palabras: si se trata de una conexión SSH y el cliente SSH pasó un terminal de color de 256 bits, ajústelo a xterm-256color , que es compatible con DietPi.

Una alternativa sería instalar un paquete que contenga más definiciones de terminal: G_AGI ncurses-term

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

@MichaIng gracias ¡Me alegro de haber podido ayudar por casualidad!

Por favor, tenga en cuenta que soy un mal administrador de sistemas y al seguir este artículo de Tom Ryder descubrí que tenía una configuración de "declaración" de terminal bastante mal configurada.

Al final, lo que solucionó el problema para mí fue

• exportando el $ TERM correcto en /root/.bashrc
• copiando la entrada terminfo correcta de mi instalación de arco en la carpeta /root/.terminfo de pi

No pude scp el archivo terminfo en mi pi, porque scp no está instalado (¿tal vez considerar instalarlo junto con el servidor dropbear?), Así que lo cargué en un servidor de mi propiedad y lo obtuve desde el pi.

Me alegro de haber podido ayudar, aplausos y lo siento de nuevo por el desastre. ¡Sigue rockeando!

@wuhei
Jep, establecer $ TERM dentro de /root/.bashrc por supuesto también funciona, agregarlo a /etc/profile[.d/] lo resuelve en todo el sistema para todos los usuarios, que es una solución que elegiríamos con DietPi.

El artículo que vinculó es bastante bueno, explica todo muy bien y las posibilidades 👍. Así que básicamente instaló manualmente el tipo de terminal requerido. El artículo también menciona el paquete ncurses-term como una opción para instalar una amplia gama de definiciones de terminal. Pero para mantener DietPi delgado, no estoy muy interesado en preinstalar este paquete para casos tan raros. En su lugar, mejor, vaya con la solución bashrc / profile; También es posible simplemente verificar el soporte del terminal antes de aplicar la corrección en el inicio de sesión SSH.

Para probar con el cliente PuTTY: PuTTY> Connection > Data > Terminal-type string

Acerca de la instalación de SCP: Existen varios otros protocolos de transferencia de archivos, FTP, SFTP o unidades de red NFS, SMB, para transferir archivos. No preinstalaría, pero dejaría la elección al usuario sobre cómo obtener archivos del cliente al servidor. Memoria USB, unidad externa, por supuesto, también es posible o simplemente copiar y pegar en el terminal SSH en el caso. Pero de todos modos, como solución general, optaría por una de las dos formas mencionadas anteriormente.