Error on feed update

Tiny Tiny RSS Support
1

Greetings,

Everything has been working fine after my recent php problem.

Something new; I get an error when my feeds should have updated.

In the system event log
Update process for feed XX terminated with non-zero exit code: 127

Here is my server information:
I’m on a shared host

Apache Version |2.4.46|
PHP Version |7.2.33|
MySQL Version |5.7.23-23|
Architecture |x86_64|
Operating System |linux| <-- all that’s provided
Perl Version |5.16.3|
Kernel Version |4.14.94-164.ELK.el7.x86_64|

What is Exit Code 127 and how can I fix it?

Thanks,
Stacey

2

moving this where it belongs

3

https://tldp.org/LDP/abs/html/exitcodes.html

It seems that you’re calling an external tool not found in the path. Maybe when update_rss_feed call for the script update.php via a php passthrough ?

4

is your PHP_EXECUTABLE well defined in config.php .?

5

Thanks Greg,

I’ve been running TT-RSS for a while now, using cron to update my feeds
/home/dovgadol/public_html/rss/update.php --feeds >/dev/null 2>&1

It worked until about mid morning today.

Thanks,
Stacey

6

THANK YOU GREG!!

Your last question directed me towards the fix.

I made the change to my config.php file and now it seems to be working

Thanks again,
Stacey

7

I am having the same issue using the daemon. My PHP_EXECUTABLE variable is defined to the correct php handler. This was not an issue until the latest update.

Apache Version |2.4.6|
PHP Version |7.3.22|
PostgreSQL Version |9.2.24|
Architecture |x86_64|
CentOS Operating System |centos-release-7-8.2003.0.el7.centos.x86_64|
Kernel Version |Linux 2.6.32-042stab120.11|

8

that’s because it wasn’t used before, now per-feed update tasks are launched as separate PHP processes.

then something else prevents it from being used. check your local configuration.

stuff like this is exactly why i’m considering to drop support for host installations entirely btw, starting at 2021. :thinking:

9

Well, I guess moving to docker should not be too much of a hassle… :grinning:

10

imo migrating the database is the only slightly annoying part, especially if you’re not used to invoking psql from inside the container (or god forbid were using mysql lol).

11

stuff like this is exactly why i’m considering to drop support for host installations entirely btw, starting at 2021. :thinking:

Please don’t drop the possibility for host installation, maybe the community can provide the support?

I don’t have docker on my personal server and I don’t want to manage a docker host: docker is useful to use, but is awful to manage as soon as you have to maintain a working docker host (must stop everything to do any update operation, incompatibility, data loss…). Or, you never do any kind of update and transform your server into a giant security hole.

So yeah, providing only a docker image and use it on a docker iaas is very comfortable, but this has backsides to. Please don’t forget them and don’t force your user to manage their own docker server or change their hosting to a docker iaas.

12

how would i even do that? you obviously would always be able to just clone the source and do whatever you want with it. the only difference is that i’m gonna scoff at your questions (more than usual). :slight_smile:

i’m running quite a bit of dockerized stuff in production and i can’t really agree with this assessment. it definitely reduced my workload.

13

how would i even do that? you obviously would always be able to just clone the source and do whatever you want with it. the only difference is that i’m gonna scoff at your questions (more than usual). :slight_smile:

Glad to see that. I have seen too many software provided with only sources, a docker and no way to understand how the sources can lead to a functional docker image – or any other way to run it :slight_smile:

i’m running quite a bit of dockerized stuff in production and i can’t really agree with this assessment. it definitely reduced my workload.

We though that in my last job. Until the first bad update that took us hours to return to a stable state.
Yes Docker is incredibly confortable on day-to-day work and software updates, and it certainly decreases the overall workload. But any operation on docker server itself is touchy and requires times if anything goes wrong (and a way to avoid problems is to stop every running services before update, which takes times too, etc). The hard point is not to run dockerized stuff, but to manage docker server itself (besides peoples trends to use Kubernetes instead of docker directly or docker-compose)