Update via cron job is scheduled every hour. Once a day I receive an email with the error in the title.
I am shared hosting and my provider asked me how to reproduce the error.
I am not sure if this is related to rss or with some settings of the server. I can not figure out if some particular feed generate the error. If I run the update manually, with --force-update as parameter I do not see any issue. error_log is also empty
…
If possible include steps to reproduce the problem:
I can not figure out how to reproduce the problem
…
tt-rss version (including git commit id):
v20.04-11a9d3b
…
Platform (i.e. Linux distro, PHP, PostgreSQL, etc) versions:
Shared hosting, (i believe) CloudLinux7, PHP 7.2.29, PostgreSQL 9.2.24
…
And what exactly is that error? It could be specific to your provider, it could be a generic “non-zero exit status”, it could be something else. And what’s in the body of this email?
I rather suspect they were being lazy, and decided to stick it just the subject of the topic, rather than in the body of the message where most people would normally expect it.
Even more lazy, since if they’d put it into google instead, they might find the answer to their problem.
I thought that using the error as subject of the topic would be easier . My mistake.
I tried googling it before posting, but I could not find anything helpful.
As I wrote in the original post, I asked the tech support of my provider and they asked how to reproduce. Maybe next time I will tell them to google it…
those kinds of warnings i think are impossible to disable, because it’s a third party library (i.e. libpng) which is invoked by a PHP module (very likely GD, while resizing an image in some particular article).
i suggest filtering it out in your cron script, there’s not much to do about it otherwise.
e: i’m assuming that this happens because of something tt-rss does, but it could really be any PHP or otherwise application.
Ah yes, I totally missed that it was in the topic here.
Still, that’s a warning, not an error per se.
The real issue is that something is causing non-zero exit status, presumably, else you’d not get an email at all. If you feel like living dangerously you could put a || exit 0 on the end of the cron job
I now realize the original post could have been written differently and I apologize.
The initial request came because I run cron with --quiet, therefore I am not expecting any email, unless something is not working.
For a couple of days though I was receiving something like this, only once a day:
libpng warning: Interlace handling should be turned on when using png_read_image
Therefore I assumed something was happening, but I was not entirely sure it was caused by TT-RSS or some misconfiguration of the server, maybe an older version of libpng.
As I am on shared hosting, I first asked them, and their answer was “how could we replicated it”.
Since I was unaware of what might have been the cause, I thought I might ask here, and then report to the hosting provider.
Usually when I want really silent cron jobs I’ll add:
&2>1 >/dev/null
>/dev/null 2>&1
to the end of the command. This sends stderr to stdout, then stdout to null. You’ll never see anything at that point. (Which could be good or bad, you decide.)
You could always redirect to a file (in truncate first mode) instead. That way you can check the last run, be that when you think there’s an issue, periodically, or, er, in another cron script .
yes, the order of your redirections, ie stdout to /dev/null then stderr to stdout, and the placement of the ampersand, ie so it applies to the redirection and not misinterpreted as backgrounding the current command, are significant.
user@localhost:~$ cat << EOF > std-out-err.sh
> #!/bin/sh
> echo stdout
> echo stderr >&2
> EOF
user@localhost:~$ sh std-out-err.sh
stdout
stderr
user@localhost:~$ sh std-out-err.sh > /dev/null
stderr
user@localhost:~$ sh std-out-err.sh 2> /dev/null
stdout
user@localhost:~$ sh std-out-err.sh > /dev/null 2>&1
user@localhost:~$ sh std-out-err.sh 2>&1 >/dev/null
stderr
user@localhost:~$ sh std-out-err.sh &2>1 >/dev/null
[1] 27589
user@localhost:~$ stdout
stderr
