Bug 24104

So is this still needed in new 29.1 release? and should this fix also bug 19127 adding:

    echo "MYTHTV_HOME=/var/lib/mythtv" >> /etc/sysconfig/mythbackend
    echo "MYTHCONFDIR=/var/lib/mythtv" >> /etc/sysconfig/mythbackend

CC: (none) => geiger.david68210

(In reply to David GEIGER from comment #1)
> So is this still needed in new 29.1 release?

Yes.

> and should this fix also bug 19127 adding:
> 
>     echo "MYTHTV_HOME=/var/lib/mythtv" >> /etc/sysconfig/mythbackend
>     echo "MYTHCONFDIR=/var/lib/mythtv" >> /etc/sysconfig/mythbackend

Yes and No. 
At the time I did not know about /etc/sysconfig/mythbackend 

It fixes problem 3 of the bug report and removes the workaround
given in comment 1.

That workaround does not fix trying to get mythtv-setup to get access to
the database. I spent 30+ hours trying to run down why mythtv-setup could
not get database access even though my install script had made all the changes.

Assigning to all packagers collectively, since the registered maintainer for this package is most likely unavailable.

CC'ing him, though.

@ David 

Feel free to take it ;-)

Assignee: bugsquad => pkg-bugs
CC: (none) => mageia, marja11

Ok, I just now rebooted my mga6 system and mythbackend would not come up but
mythtv-setup could connect because of the vars addition to 
/etc/sysconfig/mythbackend.


I placed the two variables into my drop in file workaround and mythbackend
came up.

On mga7 I only need the vars in /etc/sysconfig/mythbackend.

Fix in next mythtv-29.1-20181230.1.1.mga6 update and for cauldron too in
mythtv-29.1-20181230.2.mga7

/usr/lib/systemd/system/mythbackend.service calls for
   Environment=MYTHCONFDIR=@syscondir@/mythtv
which means there should be a /etc/sysconfig/mythtv file.


Workaround:
  echo MYTHTV_HOME=/var/lib/mythtv >> /etc/sysconfig/mythtv
  echo MYTHCONFDIR=/var/lib/mythtv >> /etc/sysconfig/mythtv

mga7 mythbackend would still not come up until adding MYTHCONFDIR to service file.

Workaround:
  mkdir -p /etc/systemd/system/mythbackend.service.d/
and create
/etc/systemd/system/mythbackend.service.d/xx__mythbackend.conf with

[Service]
Environment=MYTHTV_HOME=/var/lib/mythtv
Environment=MYTHCONFDIR=/var/lib/mythtv

> and create
> /etc/systemd/system/mythbackend.service.d/xx__mythbackend.conf with

@ maintainer/packager please use a different name for the above drop in file
if you add it to the backend package.
     Example:
          /mageia__mythbackend.conf 
I use xx__ to be able to locate my drop in/customization files.

(In reply to Bit Twister from comment #6)
> /usr/lib/systemd/system/mythbackend.service calls for
>    Environment=MYTHCONFDIR=@syscondir@/mythtv
> which means there should be a /etc/sysconfig/mythtv file.
> 
> 
> Workaround:
>   echo MYTHTV_HOME=/var/lib/mythtv >> /etc/sysconfig/mythtv
>   echo MYTHCONFDIR=/var/lib/mythtv >> /etc/sysconfig/mythtv

Instead of create a new and duplicate /etc/sysconfig/mythtv file as we have already /etc/sysconfig/mythbackend is it not simpler to just change:

Environment=MYTHCONFDIR=@syscondir@/mythtv

by

Environment=MYTHTV_HOME=/var/lib/mythtv
Environment=MYTHCONFDIR=/var/lib/mythtv

in /usr/lib/systemd/system/mythbackend.service file?

(In reply to David GEIGER from comment #8)
> 
> (In reply to Bit Twister from comment #6)

> 
> Instead of create a new and duplicate /etc/sysconfig/mythtv file as we have
> already /etc/sysconfig/mythbackend is it not simpler to just change:
> 
> Environment=MYTHCONFDIR=@syscondir@/mythtv
> 
> by
> 
> Environment=MYTHTV_HOME=/var/lib/mythtv
> Environment=MYTHCONFDIR=/var/lib/mythtv
> 
> in /usr/lib/systemd/system/mythbackend.service file?

Ideally you would want one place for a variable definition.
If you were to look through a clean install /var/log/mythtv/mythbackend*.log
the  mythdirs.cpp section of code wants to use @syscondir@/mythtv
After I created it, on next start attempt, that section quit complaining.

A quick glance at /etc/rc.d/init.d/mythbackend suggests having
/etc/sysconfig/mythbackend 

What we are seeing is a bug in mythbackend not being consistent about where to
get its environment variables or maybe a systemd bug not really using
@syscondir@whatever and setting the variables.

I don't know who is the owner of mythbackend.service file, and recommended
the mageia drop in file as a patch.

If Mageia is the owner of mythbackend.service file, then you can do as you
like, but mythbackend would still needs /etc/sysconfig/mythtv

It would be nice if mythtv.org would provide systemd files.

Ok I'll apply your proposal fixes in comment #6

And yes Mageia is the owner of mythbackend.service file.

Hmmmm! your workaround:

mkdir -p /etc/systemd/system/mythbackend.service.d/
and create
/etc/systemd/system/mythbackend.service.d/xx__mythbackend.conf with

[Service]
Environment=MYTHTV_HOME=/var/lib/mythtv
Environment=MYTHCONFDIR=/var/lib/mythtv


give on Build System:

Submission errors, aborting:
- mythtv-backend-29.1-20181230.3.mga7.i586:
 - systemd-unit-in-etc /etc/systemd/system/mythbackend.service.d/mageia__mythbackend.conf
 - systemd-unit-in-etc /etc/systemd/system/mythbackend.service.d

(In reply to David GEIGER from comment #11)
> Hmmmm! your workaround:
> 
> mkdir -p /etc/systemd/system/mythbackend.service.d/
> and create
> /etc/systemd/system/mythbackend.service.d/xx__mythbackend.conf with
> 
> [Service]
> Environment=MYTHTV_HOME=/var/lib/mythtv
> Environment=MYTHCONFDIR=/var/lib/mythtv
> 
> 
> give on Build System:
> 
> Submission errors, aborting:
> - mythtv-backend-29.1-20181230.3.mga7.i586:
>  - systemd-unit-in-etc
> /etc/systemd/system/mythbackend.service.d/mageia__mythbackend.conf
>  - systemd-unit-in-etc /etc/systemd/system/mythbackend.service.d

Weird. Sorry, I have no idea on what to say and that is why I am not a packager.
Directory is following normal drop in location for the service and here
is what I have so I know it works.

Snippet from systemctl status mythbackend

  Drop-In: /etc/systemd/system/mythbackend.service.d
           └─xx__mythbackend.conf
   Active: active (running) since Sun 2019-01-06 11:56:44 CST; 2s ago

$ cat /etc/systemd/system/mythbackend.service.d/xx__mythbackend.conf
#
#  Created by /local/bin/mythtv_changes  Thu 03 Jan 09:20 2019 
#
# https://bugs.mageia.org/show_bug.cgi?id=19127#c1
# https://bugs.mageia.org/show_bug.cgi?id=19127#c12
# https://bugs.mageia.org/show_bug.cgi?id=24104
[Service]
Environment=MYTHTV_HOME=/var/lib/mythtv
Environment=MYTHCONFDIR=/var/lib/mythtv

Since /usr/lib/systemd/system/mythbackend.service is owned by Mageia,
the easy fix would be go ahead and add them there.

   [Service]
   Type=simple
   Environment=MYTHCONFDIR=@syscondir@/mythtv
   Environment=MYTHTV_HOME=/var/lib/mythtv
   Environment=MYTHCONFDIR=/var/lib/mythtv
   User=mythtv
   ExecStart=/usr/bin/mythbackend --logpath /var/log/mythtv/

The drop in was assuming upstream owned the service file.

So please test next mythtv-29.1-20181230.3.mga7 update!

(In reply to David GEIGER from comment #14)
> So please test next mythtv-29.1-20181230.3.mga7 update!

Installed all mga7 updates this date and rebooted.

Removed the mga7 mythtv packages, removed all remaining system myth* files,
deleted  the database, disabled my mythbackend systemd drop in patch, ran my
install/change scripts. status mythbackend showed active and frontend
was able to view a recording.

Above is with myth password change, using a backup copy of database that had
already been converted from 28 to 29. 

No execution of mythtv-setup was done in this test.

So can I go with same change for mga6?

(In reply to David GEIGER from comment #16)
> So can I go with same change for mga6?

I do not see why not.
I created /etc/sysconfig/mythbackend and /etc/sysconfig/mythtv same as mga7,
Added
    Environment=MYTHTV_HOME=/var/lib/mythtv
    Environment=MYTHCONFDIR=/var/lib/mythtv
to /usr/lib/systemd/system/mythbackend.service, removed them from my drop in 
file, rebooted and backend came up. That would close this bug report as far
as I am concerned.

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2019-0223.html

Status: NEW => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED