You are here: Home » Topic » Linux: Error staring web server: Address already in use

Linux: Error staring web server: Address already in use

FireFly Media Server (formerly mt-daapd) Firefly Media Server Forums Firefly Media Server Setup Issues Linux: Error staring web server: Address already in use

This topic contains 8 replies, has 3 voices, and was last updated by  UncleOp22 10 years, 5 months ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #1262

    [email protected]
    Participant

    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?

    #9970

    rpedde
    Participant

    @[email protected] 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.

    #9971

    [email protected]
    Participant

    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?

    #9972

    rpedde
    Participant

    @[email protected] 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.

    #9973

    [email protected]
    Participant

    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.

    #9974

    [email protected]
    Participant

    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

    #9975

    rpedde
    Participant

    @[email protected] 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?

    #9976

    [email protected]
    Participant

    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 …

    #9977

    UncleOp22
    Participant

    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.

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.