Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 96977 - MythTV init script does not start mythtv due to variations in mysql.txt locations
Summary: MythTV init script does not start mythtv due to variations in mysql.txt locat...
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Television related Applications in Gentoo's Portage
URL: http://forums.gentoo.org/viewtopic-t-...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-24 12:50 UTC by MasterC
Modified: 2005-06-30 06:47 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description MasterC 2005-06-24 12:50:39 UTC
After installing mythtv, when using the init script /etc/init.d/mythbackend to
start the mythbackend, mysql.txt is created with a default file.  This file does
not work if your backend is NOT hosting your database.  If you have a modified
mysql.txt, it is overwritten upon reboot in /var/run/mythtv with the default. 
There is nowhere to identify an alternate location of this file in the conf.d
file for mythbackend.  Some have been able to successfully hack their init
script to work, others have not.

Reproducible: Always
Steps to Reproduce:
1.  emerge mythtv >=0.17
2.  Set custom database info in mysql.txt
3.  Reboot Machine
4.  Beg bug fixers to fix it ;)
Actual Results:  
MythTV appears to start, but immediately dies with the error in the mythbackend.log:
2005-06-24 13:19:00.694 New DB connection, total: 1
2005-06-24 13:19:00.695 Unable to connect to database!
2005-06-24 13:19:00.696 Driver error was [1/2002]:
QMYSQL3: Unable to connect
Database error was:
Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

2005-06-24 13:19:00.696 Failed to init MythContext, exiting.


Expected Results:  
Mythbackend should have started and continued (daemonized).  My computer should
have read the modified mysql.txt instead of overwriting it; and/or allowed for
an alternate location to read this file from.

I could post the init script here, but really it's un-necessary as it's
obviously available.
Comment 1 Doug Goldstein (RETIRED) gentoo-dev 2005-06-25 19:56:48 UTC
If you server is local then this is due to the fact that you're MySQL instance
is not starting because of a permissions problem with your MySQL directories.
The new MySQL requires that the owner be mysql:mysql and not root:mysql.

If you want to change the location of the MySQL server please use myth-setup.
Comment 2 MasterC 2005-06-28 19:17:58 UTC
(In reply to comment #1)
> If you server is local then this is due to the fact that you're MySQL 
instance
> is not starting because of a permissions problem with your MySQL directories.
> The new MySQL requires that the owner be mysql:mysql and not root:mysql.
> If you want to change the location of the MySQL server please use myth-setup.

The mythbackend is both local and remote from other frontends, but the mysql 
implementation is remote for both mythbackend and the frontends.  The problem 
is not with mysql.  You can start mythbackend directly from the command line 
and it works without a hitch.
Comment 3 Doug Goldstein (RETIRED) gentoo-dev 2005-06-28 22:58:00 UTC
Read about MySQL before commenting.

Right here in your error message... "Can't connect to local MySQL server through
socket '/var/run/mysqld/mysqld.sock' (2)"

That's a local socket. That's the proper file for Gentoo's MySQL. Which means
that if it can't connect to it via that file, then your MySQL is not running.
Due to recent upgrades with the MySQL ebuild, some people have had the issue
that I described above and it was fixed with the instructions I provided.

You did not specify in your report whether the MySQL server was local or remote
which is why I covered both bases.

Considering that the directory /var/run/mythtv is not used by the initscript NOR
by mythtv, you are once again incorrect.

The proper file to edit is /etc/mythtv/mysql.txt, which happens to be the
mysql.txt file that MythTV uses. If you want you can edit
/usr/share/mythtv/mysql.txt if you want, since it's only a symlink to
/etc/mythtv/mysql.txt

Closing this bug as invalid.
Comment 4 MasterC 2005-06-29 22:01:08 UTC
(In reply to comment #3)
> Read about MySQL before commenting.
> Right here in your error message... "Can't connect to local MySQL server 
through
> socket '/var/run/mysqld/mysqld.sock' (2)"
> That's a local socket. That's the proper file for Gentoo's MySQL. Which means
> that if it can't connect to it via that file, then your MySQL is not running.
> Due to recent upgrades with the MySQL ebuild, some people have had the issue
> that I described above and it was fixed with the instructions I provided.
> You did not specify in your report whether the MySQL server was local or 
remote
> which is why I covered both bases.
> Considering that the directory /var/run/mythtv is not used by the initscript 
NOR
> by mythtv, you are once again incorrect.
> The proper file to edit is /etc/mythtv/mysql.txt, which happens to be the
> mysql.txt file that MythTV uses. If you want you can edit
> /usr/share/mythtv/mysql.txt if you want, since it's only a symlink to
> /etc/mythtv/mysql.txt
> Closing this bug as invalid.

I appreciate your responses.  I must have not been as clear as I had thought.  
The problem is that the file mentioned gets modified/overwritten back to a 
generic mysql.txt (/var/run/mythtv) upon reboot.  If I 
edit /etc/mythtv/mysql.txt or any other mysql.txt on the entire system, upon 
reboot, the init script does not start, and it shows that error.  IF I don't 
reboot, indeed it works.  I must have made the point that the init script is 
overwriting the file, I meant to ask for the init script to point to a 
mysql.txt that isn't overwritten.

Thanks for all your hardwork.
Comment 5 Brian Jackson (RETIRED) gentoo-dev 2005-06-30 06:47:59 UTC
No mysql.txt files should be overwritten. They definitely aren't being
overwritten by the init script. Also, this doesn't seem to be happening to
anyone else. I think you need to track down what's overwriting it yourself since
we can't reproduce this.