- 20th May 2005 at 9:54 am #3298
Well, this is also the deep end of the pool. 🙂
Experimental version of the software on a hacked-together distro on an unsupported hardware platform… yeah… it’s gonna be bumpy.
Just to make it easier to see what’s going on, I’m going to add a “debug” parameter to the config file so it can be set there, rather than having to mess with the startup script. I’ll also add the stuff to print the debug level on boot.
I’m taking the day off tomorrow (yay!) so I can finish up the xml stuff. I’ll roll out fresh nightlies tomorrow, and we can see where that takes us.
— Ron21st May 2005 at 11:58 pm #3299
2005-05-18 18:28:12: Starting mp3 scan
2005-05-18 18:28:12: Starting web server from /share/hdd/data/public/conf/opt/share/mt-daapd/admin-root on port 3689
2005-05-18 18:28:12: Registering rendezvous names
Perhaps it is just me, but that path to the web admin interface looks awful screwy. Should it not simply be /opt/share/mt-daapd/admin-root (or more precisely, /share/hdd/conf/opt/share/mt-daapd/admin-root)?
The extra …data/public… in there makes me suspect there is still be some sort of path issue at play. Not sure what without more information regarding your setup. Seems like definitely something, though.
Herman23rd December 2005 at 11:09 am #3300
I also have had the /tmp permissions issue since early this year. I think it was the first build that had the sqlite dependancy, early summer?
I’m running V2.3R25-uNSLUng-standard-2.12-beta slug – I know there are newer versions out there but I’m scared to upgrade ’cause I can’t find clear instructions anywhere and I’m dependant on that little unit now – can’t have it down!
In any case, I know /tmp isn’t supposed to be 777 but I have to do that in the mt-daapd startup or else it doesn’t start the daemon. SO I have a workaround but don’t like the loose permissions. (What the heck is that special perm setting for “real” unix /tmp? I don’t have one available to me – even my tivo has /tmp loose!).
Anyway, I did have mt-daapd crash on me today for no aparent cause other than sqlite went “resource not available” on me. Of course the log is gone and I can’t recall the name of the file that got paired up with songs.db in /opt/var/mt-daapd. It was songs.db-something Aparently the DB was busy so mt-daapd couldn’t read it and all crashed.
So – any ideas on the second one? I’ll of course post more if I catch it again. Also not sure about why I have /tmp permissions issues (“glad” to see someone else does though!)
Post edited by: dougyp, at: 2005/12/23 03:1223rd December 2005 at 2:09 pm #3301
/tmp is indeed supposed to be 777. everybody has to have a guaranteed writable location, and /tmp is it. That’s what it’s for.
As far as resource not available, what version are you running? Sounds like a leak in something… memory? File handles? Something.
There were some leaks that were fixed in the last couple nightlies. The latest nightly should be (??) relatively leak free, though. So if that’s what you were running, then something is indeed screwy.
— Ron24th December 2005 at 3:00 am #3302
Thanks for the reply.
Sorry, I am running the 20051122 nightly. I truly wish I’d noted the extra songs.db file and/or the error in the mt-daapd log – my bad. I recall now that the log error said something about a playlist not existing/available even though I know it did exist – which is consistent with the daemon not able to read the DB.
At the time the failure occured I was trying to connect with a windows iTunes client and my Soundbridge was already connected. The windows client was hung and not responding. That’s when I looked at the DB dir and saw the extra file. It was something like 9M in size and my songs DB is something like 7MB in size, that just struck me as odd. The NSLU2 was a bit…slugish 😉 at the time too.
Oh – as far as /tmp permissions. I was able to find a reference machine today – it SHOULD be 1777, (not rwxrwxrwx but rwxrwxrwt) – where “t” is the sticky bit. It means that the directory is fully writeable but only for your own files, one user shouldn’t be able to read or write anothers if they aren’t in the same group. Of course now that I’m at work I don’t have access to a slug to see if “chmod 1777 /tmp” even works!
-Doug30th December 2005 at 9:56 am #3303
Following up on my post about /tmp permissions. I used to get:
2005-12-29 18:54:38: db_sqlite_open: malformed database schema – unable to open a temporary database file for storing temporary tables (/opt/var/mt-daapd/songs.db)
I fixed it by putting the following as the 2nd-to-last line in the /opt/etc/init.d/S60mt-daapd file:
chmod 1777 /tmp
Works like a charm and I have seen others reporting this problem but I had only seen a solution that suggested chmod 777 /tmp. I don’t believe that’s as secure if you have a multi-user slug 🙂
-Doug30th December 2005 at 12:44 pm #3304
That’s a good call… I’ll add that to the installer as well, just to make sure nobody else gets hit by that.
The forum ‘Setup Issues’ is closed to new topics and replies.