Pleased as punch, with my Miniflux instance.
RSS, is how I catch up with everything newsy and techy and with what people I want to hear from, have to say.
I love it.

I did face one teensy issue with it though.
Every time I rebooted my machine, the Miniflux service would fail to start.
I would just manually do a systemctl restart miniflux and it would start right up, with that innocent doggy face.


![innocent-doggie-pic.jpg ][innocent-doggie-pic]
*image courtesy, [Beverly & Pack][bp-doggie], on Flickr*

The last few days however, it’s been niggling me no end, because I have been rebooting the box ever so often.
Only when I go check up on RSS, at the end of the day or in the morning, do I realise something’s off.
So I checked up on Miniflux today, with a systemctl status miniflux
And I saw,

May 14 04:52:40 minmachine miniflux[706]: 
[FATAL] You must run the SQL migrations, 
the database schema is not up to date: current=v0 expected=v28

That did not sound right.
I religiously do a migrations step, every time it’s needed.

And then the penny dropped.
The current version of the schema, according to the error, was v0
That was not at all in line, with what I used to see, whenever I migrated.
It used to run from v25 to v26 to whatever. (These are not the actual numbers, I’m just pulling them out of my ass :P)
Not v0

It struck me that Miniflux might be starting up, before the database it uses, does.
So I just modified my Miniflux systemd script1 to startup after the database.
Like so …

[Unit]
Description=Miniflux Service
Requires=postgresql.service
After=network-online.target postgresql.service

Disable service, enable service, reboot system to check if all is well, and all that jazz …
And et voilà! Problem solved!
Miniflux and me, sitting in a tree … h-a-p-p-i-e-e!


  1. I use the helpful script miniflux.service from the docs↩︎