[SOLVED] ncmpcpp:Cannot connect to mpd:Connection closed by the server

jwhendy · 2011-02-13 16:04:22

Hi,

I've set up mpd per the second configuration option on the wiki. In other words:

$ ls -l ~/.mpd
-rw-r--r-- 1 jwhendy users  13933 Feb 13 09:20 config
-rw-r--r-- 1 jwhendy users      0 Jul  1  2010 db
-rw-r--r-- 1 jwhendy users 305914 Feb 13 08:50 mpd.db
-rw-r--r-- 1 jwhendy users      0 Jul  1  2010 mpd.error
-rw-r--r-- 1 jwhendy users      0 Jul  1  2010 mpd.log
-rw-r--r-- 1 jwhendy users      0 Jul  1  2010 mpd.pid
-rw-r--r-- 1 jwhendy users    192 Feb 13 09:20 mpdstate
drwxr-xr-x 2 jwhendy users   4096 Jul  1  2010 playlists

Also:

$ cat ~/.mpd/config
music_directory     "/path/to music"
playlist_directory     "/home/jwhendy/.mpd/playlists"
db_file                   "/home/jwhendy/.mpd/mpd.db"
state_file                "/home/jwhendy/.mpd/mpdstate"
log_file                  "/home/jwhendy/.mpd/mpd.log"
pid_file                  "/home/jwhendy/.mpd/mpd.pid"
bind_to_address        "127.0.0.1"
### the rest is commented out ###

Starting mpd works:

$ mpd .mpd/configoutput: No "audio_output" defined in config file
output: Attempt to detect audio output device
output: Attempting to detect a alsa audio device
output: Successfully detected a alsa audio device

Proof:

$ ps ax |grep mpd
4067 ?        Ssl    0:00 mpd .mpd/config
$ sudo netstate -nlp |grep mpd
tcp        0      0 127.0.0.1:6600          0.0.0.0:*               LISTEN      4067/mpd

mpd.log shows nothing odd as far as I can tell. It complains about mpdstate not existing (but afterward it exists and the error does not show up again) and then there are (I guess what I would expect) a ton of "Feb 13 timestamp: update: added /path/to/all-my-various-music" messages. It seems like mpd is doing just fine.

ncmpcpp config (extremely basic, just trying to get running):

 $ cat ~/.ncmpcpp/config
##### connection settings #####
#mpd_host = "localhost"
#mpd_port = "6600"
mpd_music_dir = "/path/to/Music"
mpd_connection_timeout = "5"
mpd_crossfade_time = "5"

the grand finale:

$ ncmpcpp
Cannot connect to mpd: Connection closed by the server

What am I doing wrong? I'm 80% expecting that it's something unbelievably stupid, but that doesn't mean I know what it is. This is my first time setting up mpd and a client. I'm clueless but want to see what the rage is around here about ncmpcpp. I currently use cmus.

Lastly, the wiki presents two methods; which is recommended (root + rc.conf or normal user with everything in ~)?

Thanks for your help.

Last edited by jwhendy (2011-02-14 01:55:11)

metzengerstein · 2011-02-13 18:03:05

Maybe its related to https://bbs.archlinux.org/viewtopic.php?id=109962
If not, run "mpd --verbose" and post the output, if you are unsure what to do next.

jwhendy · 2011-02-13 19:45:58

Thanks for the suggestions. From following the thread, it looks like the following were proposed:
1) compile without tcp_wrapper support (due to the error "libwrap refused connection")
2) add mpd to /etc/hosts.allow
3) removing the mpd.error setting from mpd config

The output form my recent starts of mpd using 'mpd --verbose .mpd/config' are like so:

Feb 13 13:39 : state_file: Loading state file /home/jwhendy/.mpd/mpdstate
Feb 13 13:40 : state_file: Saving state file /home/jwhendy/.mpd/mpdstate
Feb 13 13:40 : listen: listen_global_finish called
Feb 13 13:40 : db_finish took 0.000000 seconds
Feb 13 13:42 : state_file: Loading state file /home/jwhendy/.mpd/mpdstate

I see no libwrap issue, so I'm tempted to rule out #1.

In the thread, the consensus was that you don't need to add mpd to /etc/hosts.allow if you're using 127.0.0.1, which is what I'm doing. So I'm also tempted to rule out #2.

I don't have the mpd.error line in my config, so I'm tempted to rule out #3.

Did I miss any? I don't see anything odd from the log, assuming I called mpd --verbose correctly. Can you suggest a way to obtain better output? Can I enable something verbose in ncmpcpp?

Thanks.

jwhendy · 2011-02-13 19:49:45

Update: adding

mpd: ALL

to /etc/hosts.allow and then rebooting works.

Would someone please explain why this is necessary if I'm operating on localhost? Should this be in the wiki? The other thread suggests that this is not necessary if I'm only operating locally. Thanks.

jasonwryan · 2011-02-13 19:51:50

You could try uncommenting the port entry in .ncmpcpp/config and adding the same to .mpd/config - that works for me...

jwhendy · 2011-02-13 20:09:07

@jasonwryan: To be clear, you are talking about:

$ cat ~/.ncmpcpp/config
mpd_port = "6600"

and

$ cat ~/.mpd/config
port "6600"

Right? If so, doing that and removing the mpd line from /etc/hosts.allow does not work. I get connection refused. Could this at all be related to me running via the "normal user" way vs. the "root - daemon - /etc/rc.conf" way?

jasonwryan · 2011-02-13 20:16:38

Yes - they are the two entries that I have in my respective conf files (I don't have the bind_to_address either) with no mpd entry in hosts.allow, and I use the $HOME approach.

metzengerstein · 2011-02-13 22:45:40

I also use mpd+ncmpcpp as a normal user without a hosts.allow entry. I Played with your config settings, commenting out or in the mentioned options... it always runs flawlessly. So you shouldn't have a config problem.

I noticed that your mpd output doesn't list any daemon lines like:

...
database: reading DB
daemon: opening pid file
daemon: daemonized!
daemon: writing pid file
...

Are you sure you have not started the mpd daemon in /etc/rc.d ?
And other possibilites:
Do you have the latest packages from the arch repositories?
Do you have some uncommon firewall settings?

Btw: the other thread was related to https://bugs.archlinux.org/task/22071 , which was already fixed (i know you haven't the errors, but the same symptoms)

Last edited by metzengerstein (2011-02-13 22:46:34)

hmo_gsm · 2011-02-14 00:10:38

Asking the obvious, but you've got the following, right?

/etc/hosts
127.0.0.1 <foo> localhost

Tried this?

.ncmpcpp/config
mpd_host = "127.0.0.1"

And have you tried another client like mpc to see, if that works?

jwhendy · 2011-02-14 00:34:19

Thanks for the input, everyone. This is so puzzling! My responses:

@metzengerstein:
- weird that it works flawlessly for you...
- sorry, my posted output above was from ~/.mpd/mpd.log, not startup. Here is the result when starting mpd:

$ mpd --verbose .mpd/config
config: loading file .mpd/config
path: path_set_fs_charset: fs charset is: UTF-8
database: reading DB
output: No "audio_output" defined in config file
output: Attempt to detect audio output device
output: Attempting to detect a alsa audio device
output: Successfully detected a alsa audio device
disabling the last.fm playlist plugin because account is not configured
daemon: opening pid file
daemon: daemonized!
daemon: writing pid file

- version:

$ pacman -Q |grep mpd
mpd-git 20110213-1

- definitely no mpd in /etc/rc.conf
- no firewall
- that thread you linked to was interesting -- isn't it saying that and entry in /etc/hosts.allow is always required now?

@hme_gsm
- re. /etc/hosts... yup:

$ cat /etc/hosts
127.0.0.1    localhost.localdomain    localhost foo
::1        localhost.localdomain    localhost foo

- just tried the mpd_host line and that didn't work
- have not tried mpc, but I did try sonata and get an endless string of:

2011-02-13 18:33:05  Connection lost while reading MPD hello
2011-02-13 18:33:05  Not connected
2011-02-13 18:33:05  Not connected

Any other thoughts? Is it just that /etc/hosts.allow needs 'mpd: ALL' now? What version are the rest of you using?

skunktrader · 2011-02-14 01:08:39

The only difference between my setup (that works) and yours is that I don't have any IPV6 entries in /etc/hosts. I don't have any MPD lines in /etc/hosts.allow

jwhendy · 2011-02-14 01:52:39

@All: fixed via the suggestion to compile with "--disable libwrap", which I accomplished like so (for any else who stumble on this):

$ yaourt -S mpd-git
,-----
| Choose Y to edit PKGBUILD and scroll down to this section:
`-----

 # Configure Source
    ./autogen.sh \
        --prefix=/usr \
        --sysconfdir=/etc \
        --disable-ao \
        --disable-jack \
        --enable-bzip2 \
        --enable-httpd-output \
        --enable-iso9660 \
        --enable-lastfm \
        --enable-modplug \
        --enable-pulse \
        --enable-zzip \
        --with-zeroconf=no
,-----
| so it reads like this:
`-----
        ...
        --with-zeroconf=no \
        --disable-libwrap

Then continue with the build. Worked for me.

My only puzzlement is that unlike the issue where it's discussed HERE), I never had any "Dec 12 13:51 : client: libwrap refused connection (libwrap=mpd) from 127.0.0.1:54755" errors. Libwrap was never mentioned in my errors as far as I could tell.

In any case, it seems the fixes are either
1) add 'mpd: ALL' to /etc/hosts.allow or
2) compile with "--disable-libwrap"

I'll mark as solved but would be happy for anyone else to correct this conclusion for the benefit of others. I'll add references to this post and the other relevant ones to the wiki unless someone beats me to it.

Last edited by jwhendy (2011-02-14 01:54:42)

jwhendy · 2011-02-14 02:33:37

Update: added summary of the recent posts and bug report to the mpd page on Arch Wiki. See HERE. Edit, correct, and/or update as needed. Just wanted something there to point to the recent developments.

metzengerstein · 2011-02-14 10:19:58

If you look at the PKGBUILD of the current /extra/mpd (v. 0.16.1), you can see it gets build with "--disable-libwrap".
So have you really installed this package?

Also next time you encounter a client problem, you should first try it with mpc.

jwhendy · 2011-02-14 15:16:28

@metzengerstein:

I already answered that when you asked the first time (HERE). I said::

@metzengerstein
...
- version:
$ pacman -Q |grep mpd
mpd-git 20110213-1

I'm using aur/mpd-git, not extra/mpd 0.16.1-1.

Edit: Perhaps I should note that in the wki adds I made, as this won't be an issue for anyone using the package in [extra].

Last edited by jwhendy (2011-02-14 15:17:32)

metzengerstein · 2011-02-14 17:44:32

Sorry, didn't see that line.

Yes, I think deleting your adds could prevent the confusion with already fixed issues.

Last edited by metzengerstein (2011-02-14 17:45:49)

Rasi · 2011-02-14 21:39:15

just for information: the only way to be absolutely sure your mpd binary does not use libwrap is this:

ldd `which mpd`|grep wrap

Arch Linux

#1 2011-02-13 16:04:22

[SOLVED] ncmpcpp:Cannot connect to mpd:Connection closed by the server

#2 2011-02-13 18:03:05

Re: [SOLVED] ncmpcpp:Cannot connect to mpd:Connection closed by the server

#3 2011-02-13 19:45:58

Re: [SOLVED] ncmpcpp:Cannot connect to mpd:Connection closed by the server

#4 2011-02-13 19:49:45

Re: [SOLVED] ncmpcpp:Cannot connect to mpd:Connection closed by the server

#5 2011-02-13 19:51:50

Re: [SOLVED] ncmpcpp:Cannot connect to mpd:Connection closed by the server

#6 2011-02-13 20:09:07

Re: [SOLVED] ncmpcpp:Cannot connect to mpd:Connection closed by the server

#7 2011-02-13 20:16:38

Re: [SOLVED] ncmpcpp:Cannot connect to mpd:Connection closed by the server

#8 2011-02-13 22:45:40

Re: [SOLVED] ncmpcpp:Cannot connect to mpd:Connection closed by the server

#9 2011-02-14 00:10:38

Re: [SOLVED] ncmpcpp:Cannot connect to mpd:Connection closed by the server

#10 2011-02-14 00:34:19

Re: [SOLVED] ncmpcpp:Cannot connect to mpd:Connection closed by the server

#11 2011-02-14 01:08:39

Re: [SOLVED] ncmpcpp:Cannot connect to mpd:Connection closed by the server

#12 2011-02-14 01:52:39

Re: [SOLVED] ncmpcpp:Cannot connect to mpd:Connection closed by the server

#13 2011-02-14 02:33:37

Re: [SOLVED] ncmpcpp:Cannot connect to mpd:Connection closed by the server

#14 2011-02-14 10:19:58

Re: [SOLVED] ncmpcpp:Cannot connect to mpd:Connection closed by the server

#15 2011-02-14 15:16:28

Re: [SOLVED] ncmpcpp:Cannot connect to mpd:Connection closed by the server

#16 2011-02-14 17:44:32

Re: [SOLVED] ncmpcpp:Cannot connect to mpd:Connection closed by the server

#17 2011-02-14 21:39:15

Re: [SOLVED] ncmpcpp:Cannot connect to mpd:Connection closed by the server

Board footer