Tiny Tiny RSS: Community

Error message "Communication problem with server"

#1

Describe the problem you’re having:

  • Error message “Communication problem with server” is shown in the bottom right corner.
  • Error Console shows:
    SyntaxError: "JSON.parse: unexpected character at line 1 column 1 of the JSON data"

…

If possible include steps to reproduce the problem:
Login and wait a few seconds.
…

tt-rss version (including git commit id):
v20.01-a6d314b75
…

Platform (i.e. Linux distro, PHP, PostgreSQL, etc) versions:
Debian GNU/Linux 10 (buster)
nginx 1.14.2-2+deb10u1
mariadb-server-10.3 1:10.3.18-0+deb10u1
php7.3 7.3.11-1~deb10u1
…

Please provide any additional information below:
TTRSS is running behind an nginx reverse proxy (plain config, nothing special). It used to work flawlessly so far.
Please let me know if you need any additional information!
…

#2

there’s no information here to go on unless you want me to somehow divine the contents of that JSON data and the chain of events that led to it being broken.

you didn’t even bother to post the stacktrace for the error. look for errors in tt-rss event log and nginx/fpm logs, etc.

this could be anything up to and including your ISP MITMing you (badly) or really pretty much anything else.

#3

Thank you for the quick response.

I looked into the tt-rss event log, no errors there.

Here is the JSON content:
SyntaxError: “JSON.parse: unexpected character at line 1 column 1 of the JSON data”
handleRpcJson /js/AppBase.js?1579790635:240
onLoaded /js/Headlines.js?1579790635:574
_viewfeed_wait_timeout /js/Feeds.js?1579790635:367
onComplete /js/common.js?1572862124:26
respondToReadyState /lib/prototype.js?1572862124:1827
onStateChange /lib/prototype.js?1572862124:1756
AppBase.js:297:13

Nginx error log shows this:
8054#18054: *395788 FastCGI sent in stderr: “PHP message: PHP Fatal error: Uncaught PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away in /var/www/ttrss/include/sessions.php:119
Stack trace:
#0 /var/www/ttrss/include/sessions.php(119): PDOStatement->execute(Array)
#1 [internal function]: ttrss_write(‘8442d6ef7a1ad29…’, ‘dWlkfGk6NDQ7YXV…’)
#2 [internal function]: session_write_close()
#3 {main}
thrown in /var/www/ttrss/include/sessions.php on line 119” while reading response header from upstream, client: 123.456.789.101, server: xxx, request: “POST /backend.php HTTP/1.0”, upstream: “fastcgi://unix:/var/run/php/php7.3-fpm.sock:”, host: “xxx”

As I wrote before, I am happy to provide any information that is needed. Looks like this hints to a MySQL related error?

MITM by our ISP can be safely excluded.

#4

well done finding something useful in logs.

the usual cause for this is mysql running out of RAM. this is not really related to tt-rss at all, it’s specifically a mysql-related issue you’re having.

if you’re on a low-tier VPS i suggest trying postgres because its stock configuration (at least on debian) is really conservative with resource usage and works quite well regardless.

#5

Sorry for double posting.

Checking the logs of update_daemon2.php, I can see that the problem always occurs at the same operation (“Removing old archived feeds…”):

update_daemon2.php[4414]: [14:42:50/3800] Removing old archived feeds…
update_daemon2.php[4414]: 

Exception while creating PDO object:SQLSTATE[HY000] [2002] Connection refused
Exception while creating PDO object:SQLSTATE[HY000] [2002] Connection refused
[14:42:57/3796] removing lockfile

The VPS is an LXC container managed by me, it has 4GB RAM assigned which I deemed enough? How much would you recommend for 25 Users and 179 feeds in total (count from mysql database)?

Thanks and best regards

#6

4gb? you should have more than enough ram. i’m not sure why this could cause mysql to die. maybe there’s too many archived feeds but it seems unlikely.

you could try debugging via mysql, i.e. enable query log and see which particular query makes it “go away”.

if i were you, i’d switch to postgresql. if nothing else you’re going to see a massive increase of performance, especially if you’re running an instance for multiple users. innodb is terribly slow.

#7

I know about the drawbacks of using MariaDB and InnoDB as storage engine, but we use it on dozens of servers and don’t have a single Postgres instance … not my decision orginally.

Therefore I’d like to avoid a switch if possible.

If the server were out of RAM, I’d expect oom_reaper to kill the process, but couldn’t find any signs of that.

The MySQL Log shows a crash recovery:
[Note] InnoDB: Starting crash recovery from checkpoint LSN=31876797407
[Note] InnoDB: 1 transaction(s) which must be rolled back or cleaned up in total 46 row operations to undo

I understand that this may not be directly related to TTRSS which I think is very stable and well working in general. Thank you.

#8 
static function expire_feed_archive() {
      Debug::log("Removing old archived feeds...");

      $pdo = Db::pdo();

      if (DB_TYPE == "pgsql") {
         $pdo->query("DELETE FROM ttrss_archived_feeds
            WHERE created < NOW() - INTERVAL '1 month'");
      } else {
         $pdo->query("DELETE FROM ttrss_archived_feeds
            WHERE created < DATE_SUB(NOW(), INTERVAL 1 MONTH)");
      }
   }

this is the query that is being run (the mysql version), you can try running it in mysql CLI and see if that makes it crash.

if it does, try running something like select count(id) from ttrss_archived_feeds

#9

Might be a coincidence, as the referred statement does not cause a crash if executed manually.

I will look further into this tomorrow, thank you for your support.

#10

Problem is seemingly resolved after rebooting the server 3 days ago.

Btw, the whole setup as described is using 331MB RAM with the MySQL Backend and Nginx in front.

Thanks for the support and best regards.