Do not output cron errors

[jacen05]

Hello,

I have setup the fallback server but I receive every night an email with the cron output of the fallback script. I fixed all errors I had with the applications backup scripts, but still I receive the email. I understand that some commands and scripts do not output standard information to stdout, so I guess there is no alternative than disabling the output of the fallback backup cron task.

Here is an exemple of cron email report I got before, and that I do not get anymore:

sh: BASH_XTRACEFD : 7 : valeur non valable pour un descripteur de fichier de trace
sh: BASH_XTRACEFD : 7 : valeur non valable pour un descripteur de fichier de trace
sh: BASH_XTRACEFD : 7 : valeur non valable pour un descripteur de fichier de trace
sh: BASH_XTRACEFD : 7 : valeur non valable pour un descripteur de fichier de trace
sh: BASH_XTRACEFD : 7 : valeur non valable pour un descripteur de fichier de trace
sh: BASH_XTRACEFD : 7 : valeur non valable pour un descripteur de fichier de trace
sh: BASH_XTRACEFD : 7 : valeur non valable pour un descripteur de fichier de trace
sh: BASH_XTRACEFD : 7 : valeur non valable pour un descripteur de fichier de trace
It's hightly recommended to make your backup when the service is stopped. Please stop gitea service and with this command before to run the backup 'systemctl stop gitea.service'
sh: BASH_XTRACEFD : 7 : valeur non valable pour un descripteur de fichier de trace
sh: BASH_XTRACEFD : 7 : valeur non valable pour un descripteur de fichier de trace
sh: BASH_XTRACEFD : 7 : valeur non valable pour un descripteur de fichier de trace
sh: BASH_XTRACEFD : 7 : valeur non valable pour un descripteur de fichier de trace
sh: BASH_XTRACEFD : 7 : valeur non valable pour un descripteur de fichier de trace
sh: BASH_XTRACEFD : 7 : valeur non valable pour un descripteur de fichier de trace
sh: BASH_XTRACEFD : 7 : valeur non valable pour un descripteur de fichier de trace
sh: BASH_XTRACEFD : 7 : valeur non valable pour un descripteur de fichier de trace
Debian GNU/Linux 10
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
sending incremental file list
.d..t...... backup/
<f..t...... backup/app_list.cpt
<f..t...... backup/config.conf.cpt
[...]

Number of files: 15 (reg: 14, dir: 1)
Number of created files: 0
Number of deleted files: 0
Number of regular files transferred: 7
Total file size: 540.46M bytes
Total transferred file size: 217.29M bytes
Literal data: 217.29M bytes
Matched data: 14 bytes
File list size: 0
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 217.34M
Total bytes received: 162.42K

sent 217.34M bytes  received 162.42K bytes  7.63M bytes/sec
total size is 540.46M  speedup is 2.48

So if you're OK to not receive the cron report email, please accept the merge request. If you think it's not the correct solution, I let you implement what you think is better.

[maniackcrudelis]

Hi @jacen05

I don't know from where those BASH_XTRACEFD are coming, but I clearly see an, useless, error from gitea. But, you clearly need to know if anything bad had happened from your backup last night, that's why the standard error isn't redirected to /dev/null.

Same is true for app's backup. If something is going wrong, you have to know it.

Now... an app asking you to stop it instead of doing it itself... that's just non-sens... To mute the errors is clearly not the way I would go, better to fix apps that throw error for nothing.

[jacen05]

Hi,

I understand your point of view. Of course we have to know if something went wrong with the backup. The warning about the descriptor 7 has been happening since like forever, I posted here to see if someone has some news. But for the Gitea app backup I guess I'm left with the app maintainer or see by myself.

[maniackcrudelis]

I read the topic on the forum, I have to tell that I've never had that error. Nonetheless, a BASH_XTRACEFD error like that is likely an error from an unusual terminal or a specific situation. Anyway, the best way to solve it is to ensure the file descriptor is created before trying to use it. Especially since that file descriptor is not a common one. Anyway, not working on that anymore...

In fallback context, there isn't much you can do about it. That's probably an error on YunoHost part.

The error with gitea itself should be solved on the app part indeed. But that's actually a common error with all the packages from that guy, and last I checked, he didn't care about it... Best would be, if there's no backup hook to use, to catch the PID of the backup process and run a parallel thread to restart the service as soon as the backup is done. Should be made as a helper if really needed for the backup. But... Not my job anymore... Good luck to be heard...