Problem moving DB Backups group

[MickeyRat]

I'd like to move my dbbackup group to another mountpoint. Here's what I tried:

Stopped the backend in systemd.
Rsynced the dbbackup directory to the desired location.
Ran mythtv-setup to change the storage location.

Sounds pretty simple but, mythtv-setup crashes when I try to change the location. I want to remove the disk it's on now. I could put a symbolic link in /mnt and make it appear to be the same location. That would probably work but, it's pretty sloppy. So, how can I do this?

[bill6502]

Hi,

'crash' is a bit ambiguous. See if there's anything in the log or if it drops core.

You can use the Services API in the meantime. Host names are from an earlier post of yours,
change as required.

Code: Select all

curl --data GroupName='DB Backups' --data DirName=/somewhereElse --data HostName=zeppo zeppo:6544/Myth/AddStorageGroupDir

RemoveStorageGroupDir also works and you check them using your favorite browser:

Code: Select all

http://zeppo:6544/Myth/GetStorageGroupDirs?GroupName=DB%20Backups\&HostName=zeppo

[MickeyRat]

Hi,

'crash' is a bit ambiguous. See if there's anything in the log or if it drops core.

Thanks for the reply and you are correct. I should have been more forthcoming but, I was hoping this would be a familiar problem and someone would reply telling me the obvious thing I was overlooking. There's a core dump in the log. Here's the part right before it. Sorry, a few lines are truncated on the right but, I think it tells you what you need to know. Just to be clear. I wasn't adding a DBBACKUP group, I was attempting to change the existing one.

I can't try your solution right now. My wife's watching TV and if you got that hostname where I think you did, you know why I can't take down the backend. I'll try it early tomorrow before she gets up.

Code: Select all

Sep 15 05:37:46 zeppo sudo[5435]: pam_unix(sudo:session): session closed for user root
Sep 15 05:38:03 zeppo audit[5316]: ANOM_ABEND auid=1000 uid=0 gid=0 ses=1 pid=5316 comm="mythtv-setup" exe="/usr/bin/mythtv-setup" sig=11 res=1
Sep 15 05:38:03 zeppo kernel: audit: type=1701 audit(1568540283.804:136): auid=1000 uid=0 gid=0 ses=1 pid=5316 comm="mythtv-setup" exe="/usr/bin/mythtv-setup" sig=11 res=1
Sep 15 05:38:03 zeppo systemd[1]: Started Process Core Dump (PID 5443/UID 0).
Sep 15 05:38:03 zeppo audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@3-5443-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? >
Sep 15 05:38:03 zeppo kernel: audit: type=1130 audit(1568540283.824:137): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@3-5443-0 comm="systemd" exe="/usr/lib/systemd>
Sep 15 05:38:04 zeppo mysqld[479]: 2019-09-15  5:38:04 936 [Warning] Aborted connection 936 to db: 'mythconverg' user: 'mythtv' host: 'localhost' (Got an error reading communication packets)

[bill6502]

I should mention that the Storage Group name for backups is DB Backups, not
the "spaceless" all caps name in the Subject.

Also, to process a core file, this is the Wiki to use:

Code: Select all

https://www.mythtv.org/wiki/Debugging#Creating_a_backtrace_from_a_core_file

I did try changing the DB Backups Storage Directory both via mythtv-setup and
the Services API (on my Arch host.) Both worked OK. Full disclosure, I've got
several weeks of experience with Arch.

[MickeyRat]

I should mention that the Storage Group name for backups is DB Backups, not
the "spaceless" all caps name in the Subject.

Thanks for the reply. I'll see if I can change the subject.

I did try changing the DB Backups Storage Directory both via mythtv-setup and
the Services API (on my Arch host.) Both worked OK. Full disclosure, I've got
several weeks of experience with Arch.

As I'm sure you know, there can be numerous differences between my setup and what I'm doing and your setup and what you're doing. There's only so much that can be communicated in this medium. I'm running Arch on the box I'm on now and have for several years. However, the system I'm having trouble with is now on Manjaro which is still sort of Arch. After running myth under Arch for a couple years, I've come to the conclusion that Arch's bleeding edge philosophy adds a small amount of instability I really don't need on my myth box.

Unfortunately, I haven't been able to try any solutions yet. My wife had to get up early this morning and I can't mess with her TV watching for a while and live.

[MickeyRat]

Thanks again for the replies. Okay, I'm a bit dense here but. I don't know how to process the XML from those curl commands.

I need to let the wife calm far at least a week or two before I try to recompile MythTV. I also need to make sure she's going to be out for a while. So, I can't try that yet.

I just tried firing up the dual core I used for testing to see if I could reproduce the issue but. that didn't work. So it won't do a lot of good to recompile with debug flags there.

[MickeyRat]

I think I solved it for now. I"m a LOT more familiar with databases and sql than I am with MythTV. So, I started poking around in the database. From what I can tell, it's just the storagegroup table that needs to be modified and it doesn't appear to be linked to anything else. Here's what I did.

Code: Select all

$ mysql -u root -p mythconverg

MariaDB [mythconverg]> show columns from storagegroup;
+-----------+--------------+------+-----+---------+----------------+
| Field     | Type         | Null | Key | Default | Extra          |
+-----------+--------------+------+-----+---------+----------------+
| id        | int(11)      | NO   | PRI | NULL    | auto_increment |
| groupname | varchar(32)  | NO   | MUL | NULL    |                |
| hostname  | varchar(64)  | NO   | MUL |         |                |
| dirname   | varchar(235) | NO   |     |         |                |
+-----------+--------------+------+-----+---------+----------------+
4 rows in set (0.001 sec)

MariaDB [mythconverg]> select * from storagegroup;
+----+-------------+----------+--------------------------+
| id | groupname   | hostname | dirname                  |
+----+-------------+----------+--------------------------+
|  1 | Default     | zeppo    | /mnt/mythtv/default/     |
|  2 | LiveTV      | zeppo    | /mnt/mythtv/LiveTV/      |
|  3 | DB Backups  | zeppo    | /mnt/mythstore/dbbackup/ |
|  4 | Videos      | zeppo    | /mnt/mythtv/Videos/      |
|  5 | Trailers    | zeppo    | /mnt/mythtv/Trailers/    |
|  6 | Coverart    | zeppo    | /mnt/mythtv/Coverart/    |
|  7 | Fanart      | zeppo    | /mnt/mythtv/Fanart/      |
|  8 | Screenshots | zeppo    | /mnt/mythtv/Screenshots/ |
|  9 | Banners     | zeppo    | /mnt/mythtv/Banners/     |
| 10 | Photographs | zeppo    | /mnt/mythtv/Photographs/ |
| 11 | Music       | zeppo    | /mnt/mythtv/Music/       |
| 12 | MusicArt    | zeppo    | /mnt/mythtv/MusicArt/    |
+----+-------------+----------+--------------------------+
12 rows in set (0.000 sec)

MariaDB [mythconverg]> update storagegroup set dirname='/mnt/mythtv/dbbackup/' where id=3;
Query OK, 0 rows affected (0.000 sec)
Rows matched: 1  Changed: 0  Warnings: 0

MariaDB [mythconverg]> select * from storagegroup;
+----+-------------+----------+--------------------------+
| id | groupname   | hostname | dirname                  |
+----+-------------+----------+--------------------------+
|  1 | Default     | zeppo    | /mnt/mythtv/default/     |
|  2 | LiveTV      | zeppo    | /mnt/mythtv/LiveTV/      |
|  3 | DB Backups  | zeppo    | /mnt/mythtv/dbbackup/    |
|  4 | Videos      | zeppo    | /mnt/mythtv/Videos/      |
|  5 | Trailers    | zeppo    | /mnt/mythtv/Trailers/    |
|  6 | Coverart    | zeppo    | /mnt/mythtv/Coverart/    |
|  7 | Fanart      | zeppo    | /mnt/mythtv/Fanart/      |
|  8 | Screenshots | zeppo    | /mnt/mythtv/Screenshots/ |
|  9 | Banners     | zeppo    | /mnt/mythtv/Banners/     |
| 10 | Photographs | zeppo    | /mnt/mythtv/Photographs/ |
| 11 | Music       | zeppo    | /mnt/mythtv/Music/       |
| 12 | MusicArt    | zeppo    | /mnt/mythtv/MusicArt/    |
+----+-------------+----------+--------------------------+
12 rows in set (0.000 sec)

MariaDB [mythconverg]> commit;
Query OK, 0 rows affected (0.000 sec)

That made the directory show up correctly in myhttv-setup and when I took a test backup, it went to the correct directory. So, unless that table links somewhere I couldn't find, my immediate problem is solved.

I realize this isn't a complete solution. It doesn't help find the root issue which is either an issue with my installation (likely) or MythTV itself. I'll try to do more work on this when I stand less chance of disrupting my wife's TV watching.

[bill6502]

You're good, that's the table changed by mythtv-setup and the Services API endpoints above.

I did adjust the http://zeppo:6544/Myth/GetStorageGroupD ... Name=zeppo
example above and note that it's to be run from a browser ('cause the output is easier to read!)