[solved] "Could not update headlines" after upgrade

Tiny Tiny RSS Support
1

Describe the problem you’re having:

After logging in, the “All Articles” and “Fresh Articles” pages show “Could not update headlines (invalid object received - see error console for details)” but the error console in prefs->system is empty.

In Chrome’s javascript console, I see:
“Failed to load resource: net::ERR_INCOMPLETE_CHUNKED_ENCODING”
and
“SyntaxError: Unexpected end of JSON input”

I’ve tried browsing to the page from inside/outside my home network, from an incognito tab, with Chrome addons disabled, after clearing cookies/cache, and from both a Linux and Windows machine.

If possible include steps to reproduce the problem:

This only began after I upgraded from Debian 8 to Debian 9, which bumped postgresql from 9.4 to 9.6 and php from 5 to 7.0.

Unfortunately I’m an idiot and also pulled master to tt-rss around the same time, so I do not know which of the two broke the site.

The site seemed to work fine for a while, until more than one or two feeds were fetched (there are 36 unread right now) at which point the page started breaking.

tt-rss version (including git commit id): 36eed4d7374866f314fbdac4d00b37039674239b

Platform (i.e. Linux distro, PHP, PostgreSQL, etc) versions:

Debian 9.3
PHP 7.0
Postgresql 9.6

Please provide any additional information below:

The php and apache2 error logs are empty.

I’m pretty sure this is a dumb mistake on my part (maybe a memory limit in php or something?) but I’m just at a loss as to how to identify and fix it right now.

2

Lots of results in Google when searching this error. Have you tried any of them?

Also, can you actually view the response and response headers in your browser’s inspector and see what’s being returned by the server?

3

Thanks @JustAMacUser

The main thing I found when searching for that error was this stackoverflow post, where the solutions seem all over the place from antivirus to editing the PHP code. I don’t have antivirus like that, and haven’t tried messing around with the tt-rss code.

From this post I can view the feed json, and it’s incomplete, dropping off in the middle of an object.

I think I can see the headers in the inspector, is there anything specific I should look for? Everything is code 200, and then a call to backend.php shows failed.

4

Try temporarily changing the log destination in the config file to an empty string. That will cause PHP to log to an error file on the server itself. If PHP is exiting abruptly it may not be able to log to the default location in the database.

5

i’m using debian 9 with tt-rss right now so that’s not it, unless you managed to screw up your upgrade

6

@JustAMacUser I set define('LOG_DESTINATION', ''); in the config file, but still nothing in the PHP error log file or the syslog.

@fox That’s good to hear, though it’s totally possible I botched the upgrade.

7

How are Apache and PHP configured to interact with one another? Apache module or FPM, etc.?

How much memory? Disk space?

Any proxies? Rate-limiting? Ports blocked by the ISP?

Are you using GZip? If so, you can set the ENABLE_GZIP_OUTPUT to false in the config file and see what happens.

With PHP having enough time and memory to actually query the database and prepare a response, it seems odd that it would just stop in the middle of sending the response. Typically by that point the PHP interpreter has already generated the output and the web server has everything and is sending it to the client.

8

Thanks for the troublshooting ideas.

PHP was running as a module. I installed php-cgi and switched to that to check, and it didn’t improve anything. I’m not sure what FPM is, will look into it.

No proxies or blocked ports that I know of.

The system has 3GB of RAM, 2GB free, with 6GB of swap. the hard drive is 100GB with 15GB used.

gzip is already turned off.

9

… I enabled gzip in the configuration file just to see what would happen, and the feeds are loading now.

I’d certainly rather understand what’s actually happening and why this has fixed it, but for now tt-rss is working again. I’ll try to take some more time soon to poke around on my system and see what all is going on.

Thanks again for the troubleshooting help!

10

you mean in config.php or your httpd configuration? ENABLE_GZIP _OUTPUT definitely shouldn’t be required (i don’t have it enabled on my instance).

e: maybe some combination of gzip options break things between apache and php. if you’re using SSL gzip compression is not the best idea because it opens several protocol-related vulnerabilities.

11

I remember having weird issues with the gzip setting and cached images… but that was years ago (I think at that time I was on Debian 7 or 8, not sure). I eventually turned it off in the config file and all was well.

For the life of me I cannot think of anything that would cause the OP’s issue (or “resolution”), other than maybe some obscure Apache setting gone wrong…

e: To be fair, I haven’t touched Apache in quite a few years so I’m sure a lot has changed in that time.

12

Yeah, in tt-rss’s config.php. I just checked and apache has gzip/mod_deflate turned on too, so maybe they need to match? That doesn’t really sound right, but I don’t know.

I’m not using SSL right now, but plan to soon™, thanks for the heads up.

13

using both apache and tt-rss gzip is probably a bad idea. idk how smart apache is to not recompress everything all the time.