Linux: Error staring web server: Address already in use

[ol@fson]

Hello Readers,

i have a very strange problem with the mt-daapd server, which makes me go nuts. Maybe one of you had this problem too and can provide me some help.

I installed the mt-daapd (Version 0.2.4) on my gentoo (2.6.10-gentoo-r6) system via portage. There is absolutely no instance of mt-daapd running

ps -A | grep “mt-daapd” gives no result

and there is definately no process listening on port 3389.

netstat -a | grep “3689” gives no result

.
Looks pretty good .. so far ..
BUT, when i fire that thing up, it terminates with the following:

2007-04-10 15:13:32: Starting rendezvous daemon
2007-04-10 15:13:32: Current database version: 8
2007-04-10 15:13:32: Starting signal handler
2007-04-10 15:13:32: Loading playlists
2007-04-10 15:13:32: Initializing database
2007-04-10 15:13:32: Starting mp3 scan
2007-04-10 15:13:32: Starting web server from /usr/share/mt-daapd/admin-root on port 3689
2007-04-10 15:13:32: Could not open port: Address already in use
2007-04-10 15:13:32: Error staring web server: Address already in use
2007-04-10 15:13:32: Aborting
2007-04-10 15:13:32: Rendezvous socket closed (daap server crashed?) Aborting.
2007-04-10 15:13:32: Aborting

I am using a very small mp3 directory for testing purpose which contains just 10 files and i am not using any playlist. Here is my conf-file:

web_root /usr/share/mt-daapd/admin-root
port 3689
admin_pw ******
db_dir /var/cache/mt-daapd
mp3_dir /home/sometunes
servername firetunes
runas nobody
extensions .mp3,.m4a,.m4p
logfile /var/log/mt-daapd.log

I’ve also tried to set “runas root” but that doesn’t change anything. Once again, there is neither before or after firing it up any process listening on port 3389.
Now comes the funny part: As soon as i change the port to anything else, like 3388 or 3390 it will start!

2007-04-10 15:14:34: Starting rendezvous daemon
2007-04-10 15:14:34: Current database version: 8
2007-04-10 15:14:34: Starting signal handler
2007-04-10 15:14:34: Loading playlists
2007-04-10 15:14:34: Initializing database
2007-04-10 15:14:34: Starting mp3 scan
2007-04-10 15:14:34: Starting web server from /usr/share/mt-daapd/admin-root on port 3690
2007-04-10 15:14:34: Registering rendezvous names
2007-04-10 15:14:34: Scanned 10 songs in 0 seconds

Even more funny is, that the first time after installing it, it just worked. I tried uninstalling and recompiling the thing but the same strange behaviour appears again. I even rebooted the machine but nothing gets the stupid firefly to listen on port 3389.

I am .. very .. confused .. any idea anyone?

[rpedde]

@ol@fson wrote:

and there is definately no process listening on port 3389.

netstat -a | grep “3689” gives no result

.
Looks pretty good .. so far ..

That doesn’t mean nothing is listening on 3689. Check your /etc/services and see if there is a service name defined for 3689 and check to see if something is listening by that. It will show up by service name rather than port if there is a service name defined.

If you are getting EADDRINUSE, it’s because something is listening on that port. Guaranteed. Nothing else can cause that.

So double-check… Something else is grabbing it.

[ol@fson]

Thank you for your respond,

there was no service with that port defined in my /etc/services .. i knew there had to be something blocking that port, tho i had no idea how to find it – but then when logging in from my mac it suddenly worked. Stupid me!, i was accessing the linux machine with the firefly service from a windows ssh client which accidentally had a remote tunnel instead of a local one defined on port 3689 *duh*! So it was the sshd server which grabbed that port. Human failure, problem solved.

What is still not working is the access thru the ssh tunnel (not a remote one this time 😉 with rendevous-proxy – iTunes shows the daapd in the list but as soon as i click on it it, it tries to get the data but after a few seconds it would jump back to the local music … but as i read in other posts it’s not that easy to tunnel it .. accessing the web gui works flawlessly with the tunnel up and opening http://localhost:3689, the rendevous proxy announces the service to iTunes as it shows up in the shared music list. When i cut the tunnel and leave the proxy running, the share still shows up in iTunes but as soon as i click on it it says Error -3260, which is correct then. So the problem seems to reside on either the ssh client or server side i guess.

Update:

I just tried the tunnel connectin with just 10 files in the mp3 directory and that would work. So it seems that there is some kind of a limit? My “real” library has about 8.200 songs – maybe too much for such a tunnel?

[rpedde]

@ol@fson wrote:

I just tried the tunnel connectin with just 10 files in the mp3 directory and that would work. So it seems that there is some kind of a limit? My “real” library has about 8.200 songs – maybe too much for such a tunnel?

The only limit I could think might be the amount of time that iTunes will wait for a response. So maybe it’s just timing out. But there isn’t a set limit on the server side, no.

[ol@fson]

It doesn’t behave like a timeout tho. When i click on the share to connect, it just takes about 3 seconds until it jumps back to the local media. When connecting in my LAN it uses a lot more time and works.

[ol@fson]

It also works from remote with my macbook (using ssh and network beacon) .. so it’s just a windows (or putty or rendevous proxy) issue

[rpedde]

@ol@fson wrote:

It also works from remote with my macbook (using ssh and network beacon) .. so it’s just a windows (or putty or rendevous proxy) issue

It wouldn’t be rendezvous, it would have to be putty tunneling, but I haven’t heard anything like that.

Maybe try a cygwin port of openssh?

[ol@fson]

Yes, i tend to blame putty for it too .. tho i’ve been using putty for really a while and drilled dozens of tunnels with it without problems .. anyway, maybe it’s just a machine-specific problem. I might try another ssh client or another computer to try this. Or i might “abuse” one of the linux servers to establish the tunnel and grab it from there with the windows machine …

[UncleOp22]

I saw the “address in use” too today, while updating to 1571 on NSLU2. It was after I saw the missing FLAC library (fixed thanks to the forum). In my case, it looks like one of the old mt-daapd processes became a zombie; a reboot appears to have solved that nicely.

[Author]

Posts