Mumble Troubles

[faraon3]

Hello Everyone,

I've solved a ton of issues by searching these boards, but I've run into one I haven't be able to yet. I realize voice comm programs such as Teamspeak Vent. and Mumble aren't officially supported but I'm hoping someone could shed some light on my issue.

I managed to get Mumble up and running and can connect with the client just fine. My problem arises when I try to end my SSH session, the murmur server shuts down. I'm starting the process with "nohup ./murmur.x86 > nohup.log &". As long as I keep the SSH session open, its fine (its run for a few hours without a problem as long as I keep my terminal open and connected to bluehost). As soon as I close the SSH session and murmur tries to save to its sqlite database the process goes down.

However I do get one error in the log when I reconnect:
<F>2010-01-31 03:56:46.462 SQL Error [INSERT INTO `slog` (`server_id`, `msg`) VALUES(?,?)]: unable to open database file Unable to fetch row

I've researched the error and the two most common problems that would cause that are:

1) database corruption - this is not the case as the mumble FAQ says to run echo "pragma integrity_check;" | sqlite3 your-database-name-here.sqlite which returns "ok"

2) file descriptor limit - I'm pretty sure this isn't the problem since I used to get an error in the log that says something along the lines of "the server requires 130 file descriptors but only 100 available" to which I lowered the max users allowed to 50 and the error in the log went away.

I couldn't find any posts on these forums about mumble (well one, but it didn't have any responses) is this because its known not to work on bluehost? Any ideas? If you need any more information please let me know.

Thanks in advance!

[faraon3]

Well I found a work around, which is to change murmur to use MYSQL instead of SQLITE. To set that up the relevant portion of the murmur.ini file would look like this:

dbDriver=QMYSQL
dbUsername=username
dbPassword=userpassword
dbHost=localhost
dbPort=3306
dbPrefix=murmur_
dbOpts="UNIX_SOCKET=/tmp/mysql.sock"

Obviously you need to create the database and user from cPanel.


I'd still like to know what was going on with the sqlite database though if anyone has any ideas as thats the recommended way to run murmur.


[Edit]
Unfortunately I spoke too soon, I wasn't able to reproduce the same crash as with sqlite with MYSQL. However a new one (perhaps the same one but in a different form) has arisen. Now when a new user connects after I close the SSH session, the following fatal error appears in the logs:

<F>2010-01-31 22:11:46.813 Lost connection to SQL Database: Reconnect: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) QMYSQL: Unable to connect


Any suggestions?

[pattho]

Having same problem

Tried with screen with same result and I do have dedicated IP

[pattho]

Hopefully I am not dooming myself but looks like this works...

./murmur.x86 -v -fg >> murmur.log &
jobs -l
disown -----firstjobid----
disown ----otherjobid---
exit

Did not seem to work unless I first put murmur in foreground....

[pattho]

This has had murmur/mumble running the past 24hours
The above one died after about an hour...


./murmur.x86 -fg -v
ctrl+z
bg %1
jobs -l
disown -hr 12339
exit

[Taroven]

I've been trying to work the same issues out myself over the past couple of hours. Little hint if you're going with MySQL instead of sqlite, the socket file is located at /var/lib/mysql/mysql.sock - Took a bit of hunting to figure that out, but it works well enough. However, using MySQL seems to be fairly unreliable...

<F>2011-04-28 21:35:05.055 Lost connection to SQL Database: Reconnect: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) QMYSQL: Unable to connect

Okay, switched back to sqlite:

<F>2011-04-28 21:50:11.911 SQL Error [INSERT INTO `slog` (`server_id`, `msg`) VALUES(?,?)]: unable to open database file Unable to fetch row

Grr. Testing now with murmur.sqlite chmod'd to 777, just to see what happens. For now I'm using pattho's disown method, got a script ready for cron if I can get something stable worked out.

[Taroven]

One issue that I did notice in the process, which I'm not seeing in the latest test: Mumble was falling back to TCP mode a few seconds after connecting, saying it couldn't receive UDP packets. Oddness, hopefully that doesn't continue.