[mythtv-users] SystemD (Was: Recommended Linux Distro post CentOS)

[marcus hall]

On Sat, Dec 26, 2020 at 10:40:17AM +0000, Mike Perkins wrote:
> You aren't addressing the actual problem. This is not why systemd isn't
> restarting the myth backend but why it is failing to start in the first
> place.

Well, it's reasonable certain that the reason that mythbackend doesn't start
up is that mariadb isn't up yet.  Mariadb tells systemd that it is up before
it really is (according to notes in Fedora's distributed file for mythbackend)
and so systemd tries to start mythtbackend.  Since mythbackend can't connect
to mariadb (mariadb isn't quite ready yet), mythbackend fails.  If systemd
would just wait the Restart interval and re-try mythbackend, eventually
mariadb would start answering and it would work.  Or, if it isn't really
mariadb but something else that I don't have a dependency expressed for,
eventually that would be up and things would start.  The old init (before
systemd) would normally do this from inittab entries.  It was just annoying
that systemd didn't seem to be willing to do this.  With very little
information about why it wasn't.

> Granted, this can be some set of obscure systemd interactions at startup but
> until you investigate logically you will always have the same problem.
> 
> I would point out that most of us have no problems starting up the
> backend/host that contains the backend. Most difficulties seem to originate
> at installation time, with database connections being high on the list,
> network connections coming close. Check through as described above and see
> what you turn up.

Well, whenever I can ssh into the box, everything is up and mythbackend starts
up just fine.  Everything the backend needs is on the same box, so shouldn't
be any networking issue, mariadb seems the likely culprit.  The "right" way
to specify the dependency to systemd doesn't work, and it's just not worth
trying random hacks to poke at things to cover the race condition when it
involves rebooting the system to test it.  Especially when the problem only
happens once or twice a year.  It's "good enough".

marcus hall
marcus at tuells.org