Problem with "backup config"

Mikael Persson

When I'm trying to run the newer verion of tvheadend I got the folowing error:

2014-09-13 22:24:23.537 [ INFO] main: Log started
2014-09-13 22:24:23.559 [ INFO] config: backup: migrating config from 3.9.1464~gc6f0242 (running 3.9.1467~g0ac8cdc)
2014-09-13 22:24:23.559 [ INFO] config: backup: running, output file /home/hts/.hts/tvheadend/backup/3.9.1464~gc6f0242.tar.bz2
2014-09-13 22:24:23.601 [ ERROR] config: command '/bin/tar cjf /home/hts/.hts/tvheadend/backup/3.9.1464~gc6f0242.tar.bz2
--exclude backup .' returned error code 2
2014-09-13 22:24:23.601 [ ERROR] config: executed in directory '/home/hts/.hts/tvheadend'

2014-09-13 22:24:23.601 [ ERROR] config: backup: fatal error

Any idea what could be wrong?

ProfYaffle

What happens if you try running the tar command from the prompt as the hts user?

My guess would be permissions on something... it's trying to back up a file to which it doesn't have read permission or similar. I can't imagine why it wouldn't have write access to create the tar file, but that's another possibility. As is disc space. As is... anything else that could cause a fatal error...

Mikael Persson

When I run as user 'hts' I get the same problem:

2014-09-14 08:39:31.482 [ INFO] main: Log started
2014-09-14 08:39:31.540 [ INFO] config: backup: migrating config from 3.9.1464~gc6f0242 (running 3.9.1467~g0ac8cdc)
2014-09-14 08:39:31.540 [ INFO] config: backup: running, output file /home/hts/.hts/tvheadend/backup/3.9.1464~gc6f0242.tar.bz2
2014-09-14 08:39:31.561 [ ERROR] config: command '/bin/tar cjf /home/hts/.hts/tvheadend/backup/3.9.1464~gc6f0242.tar.bz2 --exclude backup .' returned error code 2
2014-09-14 08:39:31.561 [ ERROR] config: executed in directory '/home/hts/.hts/tvheadend'

2014-09-14 08:39:31.561 [ ERROR] config: backup: fatal error

The permissions on the 'tvheadend' folder looks like:

drwx------ 12 hts hts 4096 sep 13 22:22 tvheadend

and the 'folder' like this:

drwx------ 2 hts video 4096 sep 13 22:21 backup

ProfYaffle

Try adding -v or --verbose to the command line to see if you get more information about why it's failing.

Just thinking about permissions... despite the tvheadend daemon running as a service, I don't think it should ever be executing anything as root, so hts should have all the permissions it needs. That's the only other obvious thing to check, and that maybe depends on how you're running tvh... it's possible that you have some files owned by root (for example) that aren't readable?

Mikael Persson

Which is the command that tries to run? Is it more than:

/bin/tar cjf /home/hts/.hts/tvheadend/backup/3.9.1464~gc6f0242.tar.bz2 --exclude backup

Is there not any path to the folder to backup?

ProfYaffle

Yes - there's a dot right at the end for 'current directory':

/bin/tar cjf /home/hts/.hts/tvheadend/backup/3.9.1464~gc6f0242.tar.bz2 --exclude backup .

And your log tells you from which directory the command was executed:

2014-09-14 08:39:31.561 [ ERROR] config: executed in directory '/home/hts/.hts/tvheadend'

Mikael Persson

hts@micke-ubuntu:~/.hts/tvheadend$ /bin/tar cjf /home/hts/.hts/tvheadend/backup/3.9.1464~gc6f0242.tar.bz2 --exclude backup . -v
tar (child): /home/hts/.hts/tvheadend/backup/3.9.1464~gc6f0242.tar.bz2: Function 'open' failed: Access is denied
tar (child): Error is not recoverable: exiting now
./
./epggrab/
./epggrab/config
./epggrab/otamux/
./epggrab/otamux/a6dde77019e2b5c26425b8829cc13e87
./epggrab/otamux/88ccd421085cebd4cd4b083da4c7b5d6
./epggrab/otamux/368cf92b7ac536d305eb2bbf1249fe5f
./epggrab/otamux/d686eb913cf4999abb01340b4e0b292a
./epggrab/otamux/968002fa5da32fc32ee88837cafe068e
./epggrab/otamux/995228d36152c022703af30cf0758355
./epggrab/otamux/0c65ca51c90a603add1c3271cd9369cb
./epggrab/otamux/96284ab17711744023d2d0ae0c41b4d4

ProfYaffle

Check the permissions on everything in /home/hts/.hts/tvheadend and below. If there's a single file to which hts doesn't have read access, that would be my most likely guess. I don't know if that file list is helpful.

There are also options to suppress messages from child tar processes, I think. Have a search around.

Mikael Persson

When I run the command:

hts@micke-ubuntu:/usr/src/tvheadend$ /bin/tar cjf /home/hts/.hts/tvheadend/backup/3.9.1464~gc6f0242.tar.bz2 --exclude backup .

The backup work, but when I'm run:

hts@micke-ubuntu:/usr/src/tvheadend/build.linux$ ./tvheadend -u hts -g video

I get the following errors:

2014-09-15 19:48:24.483 [ INFO] main: Log started
2014-09-15 19:48:24.505 [ INFO] config: backup: migrating config from 3.9.1464~gc6f0242 (running 3.9.1467~g0ac8cdc)

2014-09-15 19:48:24.505 [ INFO] config: backup: running, output file /home/hts/.hts/tvheadend/backup/3.9.1464~gc6f0242.tar.bz2

2014-09-15 19:48:34.104 [ ERROR] config: command '/bin/tar cjf /home/hts/.hts/tvheadend/backup/3.9.1464~gc6f0242.tar.bz2 --exclude backup .' returned error code 2
2014-09-15 19:48:34.104 [ ERROR] config: executed in directory '/home/hts/.hts/tvheadend'
2014-09-15 19:48:34.104 [ ERROR] config: backup: fatal error

ProfYaffle

Can you grab ps -eaf (or equivalent) in the brief moment that tvheadend is running? Let's test to see if -u and -g are working... I read somewhere that they only apply if you're using -f (daemon). So you may be running as something else... perhaps it's a group permission failure, something like that.

Latty Jordan

I had what I guess is the same problem when I tried the (then) latest build this morning. The tvheadend just wouldn't start and top showed that bzip2 and tar were alternating at taking nearly 100% of cpu time. It looks like it was a bug because Revision a79cdee3 tweaks the backup thus "config: backup - exclude epggrab/*.sock files"

Latty Jordan

OK it looks like it wasn't a remporary bug for me. I've tried again with the latest version and tvheadend gets bogged down on something involving bzip2 and tar. I even gave it a couple of hours but it never got any further. I don't know if this is a memory issue, since I'm running it on a Pogoplug which only has 256M, but I've never had problems before, and top shows bzip using about 98% of CPU but only 3% of memory. For now I'm downgrading to v3.9_1358_g2746998 which has been rock solid for me.

Mikael Persson

Latty Jordan wrote:

> OK it looks like it wasn't a remporary bug for me. I've tried again with the latest version and tvheadend gets bogged down on something involving bzip2 and tar. I even gave it a couple of hours but it never got any further. I don't know if this is a memory issue, since I'm running it on a Pogoplug which only has 256M, but I've never had problems before, and top shows bzip using about 98% of CPU but only 3% of memory. For now I'm downgrading to v3.9_1358_g2746998 which has been rock solid for me.

I made a new fresh installation and now it seems to work again.

Latty Jordan

> I made a new fresh installation and now it seems to work again.

That's interesting. I've been upgrading the same installation for a while now. I didn't bother with the script to move from 3.4 to 3.9, just added back my scheduled recordings as that gave me a chance to clear some rubbish and duplicates out. Running

ls -lR /home/hts/.hts/tvheadend/ | awk '{print $3}' | sort | uniq

showed that I had files owned by two users in the tvheadend directory tree, hts and root

find /home/hts/.hts/tvheadend/ -user root

came up with a dozen or so log entries from May 2013, and I did a bulk

chown hts:video /home/hts/.hts/tvheadend/dvr/log/*

to change them all. Now the help for DVR Log retention time says:

> Time that Tvheadend will keep information about the recording in its internal database. Notice that the actual recorded file will not be deleted when the log entry is deleted.

I've got it set to 900, because I'd like to keep the log information for as long as I keep the recording, and I've got some old stuff that I've not yet got round to watching. I had however assumed that deleting the recorded file deleted the log. Maybe that's just a glitch from May 2013 that's long been corrected. Or maybe I was doing something I shouldn't have back then. Anyway, I'm just putting this up in case it may help someone else. Given that default permissions have worked OK for over a year for me, and presumably everyone else, and that this problem was caused by some orphaned rubbish, maybe the backup routines could be tweaked to skip similar files, rather than repeatedly trying and failing. I guess that's one for the developers.