Dear Maintainer,

Since I upgraded to Debian 8, the tt-rss daemon no longer starts on
boot.  It appears that when it attempts to start, MySQL is not ready.
However, I can start it manually.  I can see these errors from systemd:

tag 794960 moreinfo unreproducible
thanks

Hi,

So I tried to reproduce the problem, but for me it's working with
sysV init and with systemd. MySQL is listed as weak dependency
(Wants + After) in the tt-rss.service file, so it should be started
before tt-rss. This might be a problem with mysql reporting being
started before it has prepared the socket, though (it works for me
with a network socket).

Could you try with mysql-server-5.6 from testing, which provides
a systemd service file?

This will require me to upgrade libstdc which scares me a lot, so I
won't do that.  Instead I copied out the systemd service file and the
files that it references from the testing package and manually copied
that over to my jessie system, but it didn't help.  So I guess I will
just have to wait to see if the problem persists after I eventually
upgrade my whole system.

tag 794960 + patch
thanks

On Sat, 08 Aug 2015 11:00:31 -0700 Jeremy Malcolm <Jeremy@Malcolm.id.au>  wrote:
[...]
21~git20210204.b4cbc79+dfsg-1 on a Debian Bullseye system (managed by
FreedomBox). The problem only occurs sometimes. On boot, the service
shows as failed to start and never retries. FreedomBox uses systemd.

Even though tt-rss.service has Wants= and After= on postgresql.service,
postgresql is has Type=forking model and I don't believe it notifies
systemd after startup. Hence after spawning postgresql successfully,
tt-rss.service is immediately started. However, postgresql may be doing
house keeping duties like recovering from journal/log on power failure,
etc. and may not be accepting connections at the moment. If
postgresql.service starts quickly, tt-rss.service works. Otherwise, it
fails permanently (for that system boot).

I predict that this bug also happens in other cases. When database is
being restarted for a security upgrade (say with needsrestart package
like in case of FreedomBox) and if tt-rss tries to query at that time,
tt-rss will fail permanently.

The reason for both the bugs is that tt-rss code has exit(101) if db
connection fails. It does not try again in the next scheduled time after
waiting 120 seconds.

Both the situations are more prominent in case of slow machine like
single board computers running on SD cards like in case of FreedomBox.

Solution:

To solve both the problems comprehensively the following service options
can be introduced:

# Restart the service every 120 seconds always. When tt-rss can't
# connect to a database temporarily, it will exist with exit code 101.
# 120 seconds is the default daemon sleep interval for tt-rss.
[Service]
Restart=always
RestartSec=120s

This essentially introduces a loop around daemon that spawns it every
120 seconds after it is "done". This is the way the daemon intends to
run according to its code (barring this bug, of course). So, restarting
"always" does not seem incorrect.

Merge request available at:
https://salsa.debian.org/debian/tt-rss/-/merge_requests/3

Another way to do this is to pass options to run it a single time and
then use a systemd.timer to run it every 120 seconds.

Thanks,