I had a system problem and had to do a reinstall, also, I’ve recently upgraded to F26, so there might have been a change there but:
I’ve noticed that after a period of time, I no longer get any feed updates. If I restart the ttrss-update service, they update for awhile, and then stop.
I’m running the latest git, as of this morning July 16, 2017.
you can try collecting actual output (stdout) logs. as far as i can see not only the tasks themselves hang but actual job control is not working correctly either because there’s way too many update tasks running
personally i’m not interested in being an unpaid beta tester for redhat so i can’t really help you other than suggesting you use an actual server-grade distro to run server stuff on. if you prefer rpm that would be, for example, centos.
Yeah, I looked at the logs and didn’t really see anything… I’ll keep looking. I most likely forgot something when I reinstalled. php only went from 7.0 to 7.1 in Fedora, so that shouldn’t have made a difference.
It’s probably something I forgot to configure, but still haven’t been able to figure it out. ¯_(ツ)_/¯
I tried running from a terminal, and after about 30 minutes I start getting: [MASTER] child process 32285 seems to be stuck, aborting…
In the meantime, I just setup a cron to do it…
You should probably define DAEMON_EXTENDED_DEBUG as true in your config.php file then output the logging to a file so you can see where, exactly, the script is failing.
No, I’m running update.php --feeds. update_daemon2.php is what fails, no matter if I run it from systemd or a terminal window. What is happening with update_daemon2.php is that initially it runs fine, everything updates - but after about 30 minutes or so the child process start to hang, and they just stack up in the lock directory. I just turned on extended debug as suggested in another comment. Hopefully, that will give a clue as to what is happening.
you set tt-rss internal error logging to syslog, while your systemd unit likely outputs standard output to journald (output which has nothing to do with tt-rss error logging in the first place)
maybe you should look up how all this shit actually works because right now you’re basically pushing levers which are not connected in any way whatsoever
we already told you, define the aforementioned constant in config.php and capture daemon output
if your systemd unit which you never posted here ignores stdout or redirects it to /dev/null for whatever retarded reason just run the daemon under screen or tee or something
e: fedora users.txt
e2: well tbf i guess config.php doesn’t mention that this is strictly error logging
I’ve just found this issues as well on a newly created system. Ill try and debug too and get some info.
Im running on debian 8, php 5.6.30, Tiny Tiny RSS v17.4 (c053b97).
Thanks for the reply… I’m using Fox’s suggestion to tee the output. I’ll look into what is happening with systemd… probably some default setting in Fedora-land…
The define{‘DAEMON_EXTENDED_DEBUG’, ‘true’) didn’t really help. It printed out all kinds of information about what the process was doing, but when it failed, nothing more than I already knew:
[16:46:38/25321] [MASTER] spawned client 0 [PID:25324]…
[16:46:38/25326] Lock: update_daemon-25324.lock
[17:16:53/25321] [MASTER] child process 25324 seems to be stuck, aborting…
[17:16:53/25321] [reap_children] child 25324 reaped.
any idea what was that PID doing before it got stuck? updating some specific feed?
also i’m not sure why it is getting killed and reaped but going by your earlier post the process actually stays. i think something is broken with your php or w/e.
What if after you get a hung process you go into the database and query for the last updated feed (MAX(last_updated) or something). Once you know the feed, go to the TT-RSS web interface, select that feed and run the feed debugger f D to see how that handles it.
e: More specific query:
SELECT title FROM ttrss_feeds ORDER BY last_update_started DESC LIMIT 2;