I ran a git update yesterday and I have had trouble logging into my ttrss server since. When I login things start to load but I end up with a “Unhandled exception” error window. That says “SyntaxError: JSON parse: unexpected character at line 1 column 1 of the JSON data”
Ideas?
find error in ttrss event log, post it here
Is the event log different than the error log? Just want to make sure I give you what you ask for fox.
Here is the Stack trace shown by the browser:
backendSanityCallback@http://domain/rss/ttrss/js/AppBase.js?1550161047:292:18
constructor/<@http://domain/rss/ttrss/js/tt-rss.js?1546478549:89:8
onComplete@http://domain/rss/ttrss/js/common.js?1546478549:26:32
respondToReadyState@http://domain/rss/ttrss/lib/prototype.js?1505850259:1827:8
onStateChange@http://domain/rss/ttrss/lib/prototype.js?1505850259:1756:7
Another piece of information, the android client works just fine.
So any ideas why the android client works and the web access doesn’t?
one idea would be posting what was requested of you
I asked up above where I could find the event log or was it the same as the error log. Trying to make sure that I gave you what you asked for and in the mean time I just posted a few other pieces of information.
Preferences > System > Event Log.
Thanks, that is what I was afraid of. I cannot login to ttrss, so I can’t access the preferences.
try opening prefs.php directly
also open backend.php?op=rpc&subop=sanityCheck and see if there’s any errors in the output (it should be valid JSON)
if you can’t open prefs.php set LOG_DESTINATION to either blank string or syslog (try both) in config.php and check for error messages in apache/nginx/etc error logs when you try to open tt-rss.
e: also maybe you should post more details about your server / OS
prefs.php: I cannot open it directly, it drops me to the JSON parse error. So I will change the LOG_DESTINATION
domain/ttrss/backend.php?op=rpc&subop=sanityCheck: Requested Range Not Satisfiable
Server/OS: shared host at HostGator running Linux
$ sudo mysql ttrss_database -e 'select * from ttrss_error_log'
+----+-----------+-------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------+--------+---------+---------------------+
| id | owner_uid | errno | errstr | filename | lineno | context | created_at |
+----+-----------+-------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------+--------+---------+---------------------+
| 3 | NULL | 1 | Uncaught PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '4h6hp055h91pg9e8eqb3o923nf' for key 'PRIMARY' in /var/www/example.com/html/reader/include/sessions.php:105
Stack trace:
#0 /var/www/example.com/html/reader/include/sessions.php(105): PDOStatement->execute(Array)
#1 [internal function]: ttrss_read('4h6hp055h91pg9e...')
#2 /var/www/example.com/html/reader/api/index.php(52): session_start()
#3 {main}
thrown | include/sessions.php | 105 | | 2019-02-14 17:09:28 |
+----+-----------+-------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------+--------+---------+---------------------+
also, if you think this was caused by one of the recent git changes, try going back to an older git changeset using git checkout X (where X is changeset id from git log), try going ~10 changesets back and see if anything changes
tt-rss doesn’t generate errors like that, it seems that maybe the issue could be with your shared host
i have no idea why would error even appear when opening something through the browser because in this situation range is not specified
i think you should contact your hosting support
Thanks for the “Requested Range Not Satisfiable” not being a tt-rss. I started looking at files inside of the server and my host had added a .htaccess that was “threat mitigating” and doing that rewrite. It just happened to have been created on the same day as a git pull.
Thanks for the help in the unsupported category. As soon as I fixed the .htaccess, it works again.
see, this is why shared hosting is not supported. how would a sane person deal with stuff like this.
I don’t disagree, it is just so much cheaper…
And if you are curious here was the contents of the htaccess:
ErrorDocument 416 “Requested Range Not Satisfiable”
RewriteEngine on
RewriteCond %{THE_REQUEST} “/rss/ttrss/backend.php”
RewriteRule .* - [R=416]
l
this seems personally tailored for your install. i can’t imagine the thought process here, tbh.
not that i’m advocating it but you’d probably be better off with openshift (completely free, too) than dealing with people like that
Any host that would do this is not worth having, to be candid. There’s zero reason for this other than a lack of understanding on the host’s part.
If you have the technical know-how I’d recommend a cheap VPS. The cost is only a bit more each month and it’ll save you this type of aggravation, not to mention your stuff will probably run better. Otherwise there are some good shared hosts out there that probably won’t meddle unless there’s a real issue (email abuse, outbound attacks, malware hosting, etc.).
(I mean, the response code isn’t even a good one if they felt this script was an issue.)