Re: MPD on localhost won't work if there's no Wifi!?
Brian wrote: Bob Proulx wrote: Brian wrote: or, if the domain name is left blank, 127.0.1.1 foo would be seen. Doesn't it create an entry like this? I will need to test it in order to see what it creates in that case. 127.0.1.1 foo.localdomain foo I will try it later and report back. :-) Please do. You are correct. I just tried it. If the domain name is left blank (something I usually don't do) then what you say is what happens. 127.0.1.1 foo Bob signature.asc Description: Digital signature
Re: MPD on localhost won't work if there's no Wifi!?
On Fri 13 Jun 2014 at 15:28:48 -0600, Bob Proulx wrote:
Brian wrote:
Bob Proulx wrote:
Brian wrote:
True. What do think about the lack of '127.0.1.1 localhost' in
It is the 127.0.1.1 localhost to which I was disagreeing. That
would be unusual. It is still the loopback device so off the top of
my head I think everything should still work okay. But for best
compatibilty I think 127.0.0.1 should always be localhost the reverse.
There is quite extensive history attached to the use of 127.0.1.1 in
/etc/hosts. Parts of the most recent discussion is at:
https://lists.debian.org/debian-devel/2013/08/msg00095.html
and
https://lists.debian.org/debian-devel/2013/08/msg00151.html
If the actual hostname of the system is localhost then there is no
need for any other entry other than the 127.0.0.1 entry and the
127.0.1.1 entry isn't needed at all. (Now I need to verify that the
installer doesn't add it in that case. I recall that it does not.)
Teresa had /etc/hostname as localhost. If I do the same d-i writes my
127.0.1.1 line as
127.0.1.1localhost.lan localhost.
during an expert install.
Now that you mentioned the case of what happens if DHCP returns
something unusual I think I would need to check. But I think it still
behaves the same regardless. I don't think anything the DHCP server
returns is going to affect this. But I can't say for certain without
looking and testing. It might.
Not that I have any skills at all in understanding source code but
netcfg has
dhcp.c:if (netcfg_get_hostname(client, netcfg/dhcp_hostname,
interface-dhcp_hostname, 0))
dhcp.c: * If the netcfg/hostname preseed value is set use
that
dhcp.c: * otherwise default to the hostname returned via
DHCP, if any,
dhcp.c: * otherwise to the requested DHCP hostname
dhcp.c: * otherwise to the hostname found in DNS for the IP
address
I am more interested now in what happens in a CD#1 install completely
offline.
The hostname will be either the default (debian) or whatever is
preseeded with hostname= on the command line. I wouldn't expect there to
be a domain name.
dhcp.c:/* We don't have a domain name yet, but we need to write
out the
dhcp.c: * Default to the domain name returned via DHCP, if any
dhcp.c:di_debug(Reading domain name returned via DHCP);
dhcp.c:di_debug(DHCP domain name is '%s', domain);
netcfg-common.c: * Verify that the domain name (or FQDN) conforms to RFC
1123 s2.1, and
netcfg-common.c:} else { /* assume we have a valid domain name
given */
netcfg-common.c:/* Global var 'domain' is holding a temporary
domain name,
Suppose the server doesn't provide a domain name. Then she will have
127.0.1.1 foo
because there is no need for an alias.
That is a good question! But doesn't the installer ask you for a
domain name specifically? I believe it does. Therefore the user
should always enter a domain name. But if they don't then I don't
know what the installer puts there by default.
The default is the domain name returned via DHCP. Blanking the field
results in no domain name.
I _thought_ the installer put the special localdomain string there
in the case that the user left it empty. Because sometimes there
isn't any reasonable thing to put there. In that case it creates a
consistent and valid configuration using localhost and localdomain.
That way applications that require a domain name to be present will
have a constructed one that will work even if bogus. (As I recall
this predates RFC 2606 which created a .localhost domain.)
The idea is that some applications such as Postfix for one example,
along with others, that really want a fully qualified hostname can
have a fully consistent configuration by using localhost.localdomain.
The localdomain part is a created construct. But on an unconnected
system everything can map consistently and everything can work
regardless.
I don't pretend to understand this in its entirety, but from netcfg's
changelog:
[ Thomas Hood ]
* If there is no permanent IP address with which the system hostname
(i.e., that which is returned by the hostname command) can be
associated in /etc/hosts then associate it with address 127.0.1.1
rather than 127.0.0.1. Associating the system hostname with the
latter had the unwanted effect of making 'localhost.localdomain'
the canonical hostname associated with the system hostname.
That is, 'hostname --fqdn' returned 'localhost.localdomain'.
(Closes: #316099)
Programs that access local services at the IP address obtained by
resolving the system hostname SHOULD NOT DO THIS, but those that
do so will not be disappointed: most services that listen locally
listen on all 127/8 addresses, not just on 127.0.0.1
For an expert install the hostname and domain
Re: MPD on localhost won't work if there's no Wifi!?
On Thu 12 Jun 2014 at 16:23:37 -0600, Bob Proulx wrote: Brian wrote: Tom H wrote: Brian wrote: Teresa e Junior wrote: $ cat /etc/hostname localhost ... True. What do think about the lack of '127.0.1.1 localhost' in etc/hosts? Squeeze and Wheezy installs would both put this line in. Process check! I think you have mixed up the two cases. Since a long time now Debian installs a /etc/hosts file that will look like this: 127.0.0.1 localhost Agreed. 127.0.1.1 foo.example.comfoo Agreed - sort of :). A line in /etc/hosts has the form IP_address canonical_hostname [aliases...] aliases are optional and the second field will always be the canonical hostname. What a Debian install puts for 127.0.1.1 depends on how the install took place. If the user just uses 'install' d-i can get /etc/hostname and the domain name from whatever dhcp server is being used. 127.0.1.1 foo.example.comfoo is what the user could get. Suppose the server doesn't provide a domain name. Then she will have 127.0.1.1 foo because there is no need for an alias. For an expert install the hostname and domain name can be specified, so either 127.0.1.1 foo.example.comfoo or, if the domain name is left blank, 127.0.1.1 foo would be seen. With preseeding the hostname can be be preseeded but not the domain name. So I'd expect both the previous two variants to be possible. I do not think we are in serious disagreement. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140613191542.gx17...@copernicus.demon.co.uk
Re: MPD on localhost won't work if there's no Wifi!?
Brian wrote: Bob Proulx wrote: Brian wrote: True. What do think about the lack of '127.0.1.1 localhost' in It is the 127.0.1.1 localhost to which I was disagreeing. That would be unusual. It is still the loopback device so off the top of my head I think everything should still work okay. But for best compatibilty I think 127.0.0.1 should always be localhost the reverse. If the actual hostname of the system is localhost then there is no need for any other entry other than the 127.0.0.1 entry and the 127.0.1.1 entry isn't needed at all. (Now I need to verify that the installer doesn't add it in that case. I recall that it does not.) etc/hosts? Squeeze and Wheezy installs would both put this line in. Process check! I think you have mixed up the two cases. Since a long time now Debian installs a /etc/hosts file that will look like this: 127.0.0.1 localhost Agreed. 127.0.1.1 foo.example.comfoo Agreed - sort of :). A line in /etc/hosts has the form IP_address canonical_hostname [aliases...] aliases are optional and the second field will always be the canonical hostname. So far so good! :-) What a Debian install puts for 127.0.1.1 depends on how the install took place. If the user just uses 'install' d-i can get /etc/hostname and the domain name from whatever dhcp server is being used. Hmm... I hadn't thought about an odd DHCP configuration creating something unusual there. I am still suspicious... I think it works the same regardless. 127.0.1.1 foo.example.comfoo is what the user could get. Since I usually install things in what I consider a normal state I completely agree. That is what you would get. Now that you mentioned the case of what happens if DHCP returns something unusual I think I would need to check. But I think it still behaves the same regardless. I don't think anything the DHCP server returns is going to affect this. But I can't say for certain without looking and testing. It might. I am more interested now in what happens in a CD#1 install completely offline. Suppose the server doesn't provide a domain name. Then she will have 127.0.1.1 foo because there is no need for an alias. That is a good question! But doesn't the installer ask you for a domain name specifically? I believe it does. Therefore the user should always enter a domain name. But if they don't then I don't know what the installer puts there by default. I _thought_ the installer put the special localdomain string there in the case that the user left it empty. Because sometimes there isn't any reasonable thing to put there. In that case it creates a consistent and valid configuration using localhost and localdomain. That way applications that require a domain name to be present will have a constructed one that will work even if bogus. (As I recall this predates RFC 2606 which created a .localhost domain.) The idea is that some applications such as Postfix for one example, along with others, that really want a fully qualified hostname can have a fully consistent configuration by using localhost.localdomain. The localdomain part is a created construct. But on an unconnected system everything can map consistently and everything can work regardless. For an expert install the hostname and domain name can be specified, so either 127.0.1.1 foo.example.comfoo or, if the domain name is left blank, 127.0.1.1 foo would be seen. Doesn't it create an entry like this? I will need to test it in order to see what it creates in that case. 127.0.1.1 foo.localdomain foo I will try it later and report back. :-) With preseeding the hostname can be be preseeded but not the domain name. So I'd expect both the previous two variants to be possible. The domain *can* be preseeded. I do that all of the time. Really! On the install command line. For me usually through the PXE network boot syslinux interface. hostname=junk domain=proulx.com I do not think we are in serious disagreement. Sometimes we disagree but it is never serious. I always look forward to your postings Brian. They are always high quality helpful postings. I enjoy our discussions. Bob signature.asc Description: Digital signature
Re: MPD on localhost won't work if there's no Wifi!?
Brian wrote: Tom H wrote: Brian wrote: Teresa e Junior wrote: $ cat /etc/hostname localhost ... True. What do think about the lack of '127.0.1.1 localhost' in etc/hosts? Squeeze and Wheezy installs would both put this line in. Process check! I think you have mixed up the two cases. Since a long time now Debian installs a /etc/hosts file that will look like this: 127.0.0.1 localhost 127.0.1.1 foo.example.comfoo That way 127.0.0.1 maps to localhost and localhost maps to 127.0.0.1 and this is always independent of whether networking is up or down. That is just the default and of course may be locally modified. I think it is a good default. I do have some special cases that need this to be adjusted otherwise but good as a general purpose default. Additionally the hostname always uses the loopback device. Again this allows applications to work using the hostname regardless of the state of other network devices. Bob signature.asc Description: Digital signature
Re: MPD on localhost won't work if there's no Wifi!?
On Tue, 10 Jun 2014 08:22:58 +0300, Andrei POPESCU wrote: As far as I can tell mpc is low-level enough to not care about what Network Manager advertises. I'm suspecting it does have something to do with DNS, so I'd suggest you pick a name for your machine and make sure you adjust your configs as follows (assuming your machine's name is 'mpdserver'): /etc/hostname: mpdserver /etc/hosts: 127.0.0.1 localhost 127.0.1.1 mpdserver (you can also use the lan IP here if it is fixed and enabling the IPv6 entries could also help) mpd.conf: bind_to_address localhost After making all these changes exactly as you have mentioned, I wouldn't see that error anymore. But because I'm curious, I decided to investigate what was the culprit, and I found that leaving bind_to_address as localhost and enabling the IPv6 entries in /etc/hosts was enough. Then I commented the entries again in /etc/hosts and immediately mpc stopped working. If you make all these changes it's probably a good idea to reboot. If mpc still can't connect please post the output of: getent hosts localhost getent hosts mpdserver # or whatever you named it netstat -plant | grep mpd with and without Network Manager running. The old getent output, from when it was not working: $ getent hosts localhost 127.0.0.1 localhost The old getent output, from when it was working: $ getent hosts localhost 127.0.0.1 localhost And sometimes: ::1 localhost The new getent output: $ getent hosts localhost ::1 localhost ip6-localhost ip6-loopback Always netstat has shown this: $ netstat -plant | grep mpd tcp 0 0 127.0.0.1:6600 0.0.0.0:*LISTEN 4062/mpd tcp60 0 ::1:6600:::* LISTEN 4062/mpd Thanks really a lot to everyone for this! Teresa and Junior -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5396e7ae.3060...@gmail.com
Re: MPD on localhost won't work if there's no Wifi!?
On Mon, 9 Jun 2014 09:53:31 +0400, Reco wrote:
Your network configuration may be the cause of this. Can you please run
mpc like this, and show the result:
strace -e trace=network mpc
$ strace -e trace=network mpc
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/mpd/socket}, 110) = -1
ENOENT (No such file or directory)
socket(PF_NETLINK, SOCK_RAW, 0) = 3
bind(3, {sa_family=AF_NETLINK, pid=0, groups=}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=20150, groups=}, [12]) = 0
sendto(3, \24\0\0\0\26\0\1\3\301L\225S\0\0\0\0\0\0\0\0, 20, 0,
{sa_family=AF_NETLINK, pid=0, groups=}, 12) = 20
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{D\0\0\0\24\0\2\0\301L\225S\266N\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 148
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{@\0\0\0\24\0\2\0\301L\225S\266N\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 128
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{\24\0\0\0\3\0\2\0\301L\225S\266N\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 20
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/nscd/socket}, 110) = -1
ENOENT (No such file or directory)
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/nscd/socket}, 110) = -1
ENOENT (No such file or directory)
socket(PF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_TCP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(6600),
sin_addr=inet_addr(127.0.0.1)}, 16) = -1 EINPROGRESS (Operation now in
progress)
getsockopt(3, SOL_SOCKET, SO_ERROR, [111], [4]) = 0
error: Connection refused
Also, you can try adding the following to your mpd.conf to workaround
this problem:
bind_to_address /run/mpd/socket
I have tried using a socket instead some months ago and I don't remember
what went wrong, but I may try that again.
Thanks for your answer!
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53954dda.7090...@gmail.com
Re: MPD on localhost won't work if there's no Wifi!?
On Mon, 09 Jun 2014 02:02:02 -0400
Teresa e Junior teresaejun...@gmail.com wrote:
On Mon, 9 Jun 2014 09:53:31 +0400, Reco wrote:
Your network configuration may be the cause of this. Can you please run
mpc like this, and show the result:
strace -e trace=network mpc
$ strace -e trace=network mpc
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/mpd/socket}, 110) = -1
ENOENT (No such file or directory)
So, mpc tries standard mpd socket and fails. Adding said socket to
mpd.conf (via bind_address) should solve the issue.
socket(PF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_TCP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(6600),
sin_addr=inet_addr(127.0.0.1)}, 16) = -1 EINPROGRESS (Operation now in
progress)
getsockopt(3, SOL_SOCKET, SO_ERROR, [111], [4]) = 0
error: Connection refused
And that's interesting. mpc tries to connect to 127.0.0.1:6600 and
fails, but the error shows 'connection refused', not 'failed to resolve
hostname'. Is your mpd running?
Reco
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20140609103009.4808500efc2461a74d363...@gmail.com
Re: MPD on localhost won't work if there's no Wifi!?
On Mon, 9 Jun 2014 10:30:09 +0400, Reco wrote:
So, mpc tries standard mpd socket and fails. Adding said socket to
mpd.conf (via bind_address) should solve the issue.
Just adding a path to the socket doesn't really solve the issue (I run
MPD as my user, so there is no access to /var/run). I tried removing
/etc/mpd.conf, but strace tells me MPD still tries to find the sockets
in /var/run, and seems to ignore a socket specified in bind_to_address
in my .mpd/mpd.conf:
bind_to_address /home/teresaejunior/.mpd/socket
But I got it to work by running:
MPD_HOST=~/.mpd/socket mpc
And that's interesting. mpc tries to connect to 127.0.0.1:6600 and
fails, but the error shows 'connection refused', not 'failed to resolve
hostname'. Is your mpd running?
For this I deeply regret, because I generally leave MPD running, but I
had to reboot (which I don't do often, I almost always just hibernate),
and so MPD was not running. The problem I mentioned does exist, but the
strace I have sent is wrong. Here are the proper strace logs without
setting the socket in mpd.conf: the first tries the /var/run/ sockets,
but the second doesn't, and the third works because the Wifi has been
connected:
$ strace -e trace=network mpc
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/mpd/socket}, 110) = -1
ENOENT (No such file or directory)
socket(PF_NETLINK, SOCK_RAW, 0) = 3
bind(3, {sa_family=AF_NETLINK, pid=0, groups=}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=1050, groups=}, [12]) = 0
sendto(3, \24\0\0\0\26\0\1\3=Z\225S\0\0\0\0\0\0\0\0, 20, 0,
{sa_family=AF_NETLINK, pid=0, groups=}, 12) = 20
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{D\0\0\0\24\0\2\0=Z\225S\32\4\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 68
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{@\0\0\0\24\0\2\0=Z\225S\32\4\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 128
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{\24\0\0\0\3\0\2\0=Z\225S\32\4\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 20
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/nscd/socket}, 110) = -1
ENOENT (No such file or directory)
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/nscd/socket}, 110) = -1
ENOENT (No such file or directory)
error: Failed to resolve host name
$ MPD_HOST=127.0.0.1 strace -e trace=network mpc
socket(PF_NETLINK, SOCK_RAW, 0) = 3
bind(3, {sa_family=AF_NETLINK, pid=0, groups=}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=1089, groups=}, [12]) = 0
sendto(3, \24\0\0\0\26\0\1\3CZ\225S\0\0\0\0\0\0\0\0, 20, 0,
{sa_family=AF_NETLINK, pid=0, groups=}, 12) = 20
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{D\0\0\0\24\0\2\0CZ\225SA\4\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 68
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{@\0\0\0\24\0\2\0CZ\225SA\4\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 128
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{\24\0\0\0\3\0\2\0CZ\225SA\4\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 20
error: Failed to resolve host name
$ strace -e trace=network mpc
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/mpd/socket}, 110) = -1
ENOENT (No such file or directory)
socket(PF_NETLINK, SOCK_RAW, 0) = 3
bind(3, {sa_family=AF_NETLINK, pid=0, groups=}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=6262, groups=}, [12]) = 0
sendto(3, \24\0\0\0\26\0\1\3\305^\225S\0\0\0\0\0\0\0\0, 20, 0,
{sa_family=AF_NETLINK, pid=0, groups=}, 12) = 20
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{D\0\0\0\24\0\2\0\305^\225Sv\30\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 148
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{@\0\0\0\24\0\2\0\305^\225Sv\30\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 128
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{\24\0\0\0\3\0\2\0\305^\225Sv\30\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 20
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/nscd/socket},
Re: MPD on localhost won't work if there's no Wifi!?
On Mon, Jun 09, 2014 at 03:16:00AM -0400, Teresa e Junior wrote: On Mon, 9 Jun 2014 10:30:09 +0400, Reco wrote: So, mpc tries standard mpd socket and fails. Adding said socket to mpd.conf (via bind_address) should solve the issue. Just adding a path to the socket doesn't really solve the issue (I run MPD as my user, so there is no access to /var/run). I tried removing /etc/mpd.conf, but strace tells me MPD still tries to find the sockets in /var/run, and seems to ignore a socket specified in bind_to_address in my .mpd/mpd.conf: bind_to_address /home/teresaejunior/.mpd/socket But I got it to work by running: MPD_HOST=~/.mpd/socket mpc Good. Now there's only the network issue left. For this I deeply regret, because I generally leave MPD running, but I had to reboot (which I don't do often, I almost always just hibernate), and so MPD was not running. The problem I mentioned does exist, but the strace I have sent is wrong. Here are the proper strace logs without setting the socket in mpd.conf: the first tries the /var/run/ sockets, but the second doesn't, and the third works because the Wifi has been connected: Ok. Thinking about it, I beleive I may miss something. What does show: strace -f mpc Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140609074913.ga20...@d1696.int.rdtex.ru
Re: MPD on localhost won't work if there's no Wifi!?
On Mon, 9 Jun 2014 11:49:15 +0400, Reco wrote:
Ok. Thinking about it, I beleive I may miss something. What does show:
strace -f mpc
OK, the first log is from when it fails, and the second from when the
Wifi is connected. You'll see it reads from /etc/hosts more than just
127.0.0.1 localhost, but the rest are just comments, and so I tried
removing them, but it didn't make any difference.
$ strace -f mpc
execve(/usr/bin/mpc, [mpc], [/* 36 vars */]) = 0
brk(0) = 0x898e000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb77b
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=72902, ...}) = 0
mmap2(NULL, 72902, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb779e000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/i386-linux-gnu/i686/cmov/libnsl.so.1, O_RDONLY) = 3
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P1\0\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=79728, ...}) = 0
mmap2(NULL, 92136, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0xb7787000
mmap2(0xb779a000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12) = 0xb779a000
mmap2(0xb779c000, 6120, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb779c000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/usr/lib/libmpdclient.so.2, O_RDONLY) = 3
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20N\0\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=57612, ...}) = 0
mmap2(NULL, 60332, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0xb7778000
mmap2(0xb7786000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd) = 0xb7786000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/i386-linux-gnu/i686/cmov/libc.so.6, O_RDONLY) = 3
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240o\1\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1441960, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb000
mmap2(NULL, 1456504, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0xb7613000
mprotect(0xb777, 4096, PROT_NONE) = 0
mmap2(0xb7771000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15d) = 0xb7771000
mmap2(0xb7774000, 10616, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7774000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7612000
set_thread_area({entry_number:-1 - 6, base_addr:0xb76126c0,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7771000, 8192, PROT_READ) = 0
mprotect(0xb779a000, 4096, PROT_READ) = 0
mprotect(0x8053000, 4096, PROT_READ)= 0
mprotect(0xb77cf000, 4096, PROT_READ) = 0
munmap(0xb779e000, 72902) = 0
brk(0) = 0x898e000
brk(0x89af000) = 0x89af000
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo
...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo
...}) = 0
open(/usr/lib/locale/locale-archive, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=1534512, ...}) = 0
mmap2(NULL, 1534512, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb749b000
close(3)= 0
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/mpd/socket}, 110) = -1
ENOENT (No such file or directory)
close(3)= 0
socket(PF_NETLINK, SOCK_RAW, 0) = 3
bind(3, {sa_family=AF_NETLINK, pid=0, groups=}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=18616, groups=}, [12]) = 0
time(NULL) = 1402300434
sendto(3, \24\0\0\0\26\0\1\3\22h\225S\0\0\0\0\0\0\0\0, 20, 0,
{sa_family=AF_NETLINK, pid=0, groups=}, 12) = 20
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{D\0\0\0\24\0\2\0\22h\225S\270H\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 68
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{@\0\0\0\24\0\2\0\22h\225S\270H\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 128
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
Re: MPD on localhost won't work if there's no Wifi!?
On Mon 09 Jun 2014 at 01:23:43 -0400, Teresa e Junior wrote: $ cat /etc/hostname localhost I wouldn't use this in /etc/hostname. Contacting this machine from elsewhwere on the network could prove frustrating. $ cat /etc/hosts 127.0.0.1 localhost This line is the complete contents of /etc/hosts? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/09062014094928.aadbd698f...@desktop.copernicus.demon.co.uk
Re: MPD on localhost won't work if there's no Wifi!?
On Lu, 09 iun 14, 01:23:43, Teresa e Junior wrote: Hello to all! I've had this problem with previous versions of MPD, and now I'm using 0.18.7, but the problem persists. This is an odd situation: MPD is configured to run on 127.0.0.1, but if the Wifi is disconnected in NetworkManager, it starts spitting error messages and refuses to play: Could you please post the output of 'ip a' after you disconnect the WiFi? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: MPD on localhost won't work if there's no Wifi!?
On Mon, Jun 09, 2014 at 04:04:21AM -0400, Teresa e Junior wrote: On Mon, 9 Jun 2014 11:49:15 +0400, Reco wrote: Ok. Thinking about it, I beleive I may miss something. What does show: strace -f mpc OK, the first log is from when it fails, and the second from when the Wifi is connected. You'll see it reads from /etc/hosts more than just 127.0.0.1 localhost, but the rest are just comments, and so I tried removing them, but it didn't make any difference. Weird. Just weird. Try it like this: 1) Start as root: /usr/sbin/tcpdump -nn -i any udp port 53 or udp port 5353 2) Run mpc in another shell. 3) Please post the contents of your /etc/nsswitch.conf Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140609092719.ga29...@d1696.int.rdtex.ru
Re: MPD on localhost won't work if there's no Wifi!?
On Mon, 9 Jun 2014 09:55:06 +0100, Brian wrote: On Mon 09 Jun 2014 at 01:23:43 -0400, Teresa e Junior wrote: $ cat /etc/hostname localhost I wouldn't use this in /etc/hostname. Contacting this machine from elsewhwere on the network could prove frustrating. I think that is or was a basic default for desktops without a network, correct me if I'm wrong... I've been using Debian for so long I can't remember where I got this from! $ cat /etc/hosts 127.0.0.1 localhost This line is the complete contents of /etc/hosts? Yes, with a few more commented lines: # The following lines are desirable for IPv6 capable hosts #::1 localhost ip6-localhost ip6-loopback #fe00::0 ip6-localnet #ff00::0 ip6-mcastprefix #ff02::1 ip6-allnodes #ff02::2 ip6-allrouters #ff02::3 ip6-allhosts Thanks for your attention! Teresa and Junior -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53958a88.7030...@gmail.com
Re: MPD on localhost won't work if there's no Wifi!?
On Mon, Jun 9, 2014 at 4:55 AM, Brian a...@cityscape.co.uk wrote: On Mon 09 Jun 2014 at 01:23:43 -0400, Teresa e Junior wrote: $ cat /etc/hostname localhost I wouldn't use this in /etc/hostname. Contacting this machine from elsewhwere on the network could prove frustrating. The hostname in /etc/hostname isn't necessarily the hostname used to access a box remotely; although it makes sense for them to be the same. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOdo=SwjPrJWducahzX7-PT-==juhskq4membpr17xbbcks...@mail.gmail.com
Re: MPD on localhost won't work if there's no Wifi!?
On Mon 09 Jun 2014 at 07:58:41 -0400, Tom H wrote: On Mon, Jun 9, 2014 at 4:55 AM, Brian a...@cityscape.co.uk wrote: On Mon 09 Jun 2014 at 01:23:43 -0400, Teresa e Junior wrote: $ cat /etc/hostname localhost I wouldn't use this in /etc/hostname. Contacting this machine from elsewhwere on the network could prove frustrating. The hostname in /etc/hostname isn't necessarily the hostname used to access a box remotely; although it makes sense for them to be the same. True. What do think about the lack of '127.0.1.1 localhost' in etc/hosts? Squeeze and Wheezy installs would both put this line in. (Neither may have anything to do with the OP's problem). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140609121013.gw17...@copernicus.demon.co.uk
Re: MPD on localhost won't work if there's no Wifi!?
On Mon, 9 Jun 2014 11:56:25 +0300, Andrei POPESCU wrote: Could you please post the output of 'ip a' after you disconnect the WiFi? Just in case, I'm posting the output of both when the Wifi is off and on: $ ip a 1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast state DOWN qlen 50 link/ether 80:ee:73:1f:6d:47 brd ff:ff:ff:ff:ff:ff 3: wlan0: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc mq state DOWN qlen 50 link/ether 68:a3:c4:4d:6a:b5 brd ff:ff:ff:ff:ff:ff inet6 fe80::6aa3:c4ff:fe4d:6ab5/64 scope link valid_lft forever preferred_lft forever $ ip a 1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast state DOWN qlen 50 link/ether 80:ee:73:1f:6d:47 brd ff:ff:ff:ff:ff:ff 3: wlan0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc mq state UP qlen 50 link/ether 68:a3:c4:4d:6a:b5 brd ff:ff:ff:ff:ff:ff inet 192.168.0.11/24 brd 192.168.0.255 scope global wlan0 valid_lft forever preferred_lft forever inet6 fe80::6aa3:c4ff:fe4d:6ab5/64 scope link valid_lft forever preferred_lft forever Thanks for your attention! Teresa and Junior -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5395aaec.6000...@gmail.com
Re: MPD on localhost won't work if there's no Wifi!?
On Mon, 9 Jun 2014 13:27:21 +0400, Reco wrote: Weird. Just weird. Try it like this: 1) Start as root: /usr/sbin/tcpdump -nn -i any udp port 53 or udp port 5353 2) Run mpc in another shell. 3) Please post the contents of your /etc/nsswitch.conf Nothing really happens in the tcpdump window when I run mpc, and the strace from mpc is the same as I posted in the previous email. $ sudo /usr/sbin/tcpdump -nn -i any udp port 53 or udp port 5353 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 07:21:38.107587 IP 127.0.0.1.54697 127.0.0.1.53: 5034+ A? r.usyncapp.com. (32) 07:21:38.107679 IP 127.0.0.1.59934 127.0.0.1.53: 5034+ A? r.usyncapp.com. (32) 07:21:38.107729 IP 127.0.0.1.33801 127.0.0.1.53: 5034+ A? r.usyncapp.com. (32) 07:21:38.107776 IP 127.0.0.1.60126 127.0.0.1.53: 5034+ A? r.usyncapp.com. (32) 07:21:48.119928 IP 127.0.0.1.33260 127.0.0.1.53: 11163+ A? r.usyncapp.com. (32) 07:21:48.120056 IP 127.0.0.1.47878 127.0.0.1.53: 11163+ A? r.usyncapp.com. (32) 07:21:48.120097 IP 127.0.0.1.56108 127.0.0.1.53: 11163+ A? r.usyncapp.com. (32) 07:21:48.120119 IP 127.0.0.1.54904 127.0.0.1.53: 11163+ A? r.usyncapp.com. (32) ^C 8 packets captured 16 packets received by filter 0 packets dropped by kernel $ mpc error: Failed to resolve host name $ cat /etc/nsswitch.conf # /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # If you have the `glibc-doc-reference' and `info' packages installed, try: # `info libc Name Service Switch' for information about this file. passwd: compat group: compat shadow: compat hosts: files dns networks: files protocols: db files services: db files ethers: db files rpc:db files netgroup: nis -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5395aaf4.4040...@gmail.com
Re: MPD on localhost won't work if there's no Wifi!?
On Mon, Jun 9, 2014 at 8:10 AM, Brian a...@cityscape.co.uk wrote: On Mon 09 Jun 2014 at 07:58:41 -0400, Tom H wrote: On Mon, Jun 9, 2014 at 4:55 AM, Brian a...@cityscape.co.uk wrote: On Mon 09 Jun 2014 at 01:23:43 -0400, Teresa e Junior wrote: $ cat /etc/hostname localhost I wouldn't use this in /etc/hostname. Contacting this machine from elsewhwere on the network could prove frustrating. The hostname in /etc/hostname isn't necessarily the hostname used to access a box remotely; although it makes sense for them to be the same. True. What do think about the lack of '127.0.1.1 localhost' in etc/hosts? Squeeze and Wheezy installs would both put this line in. (Neither may have anything to do with the OP's problem). Good point! If the OP's problem has to do with dns resolution and the OP's using NM, then the lack of a 127.0.1.1 entry is probably a problem because NM uses dnsmasq by default and /etc/resolv.conf is then set to 127.0.1.1. Otherwise, if the hostname is localhost, a 127.0.1.1 entry isn't needed. If the hostname is tomh, such an entry is needed for tomh to be resolvable locally. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOdo=swaysrca6sd9pa4514zrekm9dpx0_e3khgyxrrrqw7...@mail.gmail.com
Re: MPD on localhost won't work if there's no Wifi!?
On Mon, Jun 9, 2014 at 8:39 AM, Teresa e Junior teresaejun...@gmail.com wrote: $ sudo /usr/sbin/tcpdump -nn -i any udp port 53 or udp port 5353 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 07:21:38.107587 IP 127.0.0.1.54697 127.0.0.1.53: 5034+ A? r.usyncapp.com. (32) $ mpc error: Failed to resolve host name So the hostname that it's failing to resolve is r.usyncapp.com. For testing only!: Does mpc run without the network being up if you add 127.0.2.2 r.usyncapp.com. (Trying to determine whether mpc needs something from that host or whether it just needs to resolve the hostname.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOdo=szqwkborde3jmce8ryvzqjozkhdhnaredkbu4wob8j...@mail.gmail.com
Re: MPD on localhost won't work if there's no Wifi!?
On Mon, Jun 9, 2014 at 9:58 PM, Tom H tomh0...@gmail.com wrote: On Mon, Jun 9, 2014 at 4:55 AM, Brian a...@cityscape.co.uk wrote: On Mon 09 Jun 2014 at 01:23:43 -0400, Teresa e Junior wrote: $ cat /etc/hostname localhost I wouldn't use this in /etc/hostname. Contacting this machine from elsewhwere on the network could prove frustrating. The hostname in /etc/hostname isn't necessarily the hostname used to access a box remotely; although it makes sense for them to be the same. It might not confuse software, but it'll certainly confuse the wetware. I have one primary keyboard/screen/mouse, attached to the computer named 'sikorsky', and then manage most of the network via SSH from there. If I type ssh yosemite, I expect the bash prompt to show rosuav@yosemite. :) ChrisA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/captjjmpfdu-h-gko0+pw-mzbhyuekhwz_cfopndfmet8aj8...@mail.gmail.com
Re: MPD on localhost won't work if there's no Wifi!?
I believe it's got something to do with NetworkManager, because mpc started working as soon as I run: $ sudo service network-manager stop And then I run this, and while trying to connect, or later if connecting fails, mpc won't work again: $ sudo service network-manager start The version of NetworkManager installed is 0.9.4.0-10 on wheezy. I believe NM kind of advertises to the system if there is a connection available. As an example, if configured as such, Claws Mail will only check for emails based on information passed by NetworkManager. On Mon, 9 Jun 2014 10:46:12 -0400, Tom H wrote: For testing only!: Does mpc run without the network being up if you add 127.0.2.2 r.usyncapp.com. (Trying to determine whether mpc needs something from that host or whether it just needs to resolve the hostname.) r.usyncapp.com. has something to do with Bittorrent Sync, but disabling btsync or adding that line to /etc/hosts won't make any difference. On Mon, 9 Jun 2014 10:46:12 -0400, Tom H wrote: If the OP's problem has to do with dns resolution and the OP's using NM, then the lack of a 127.0.1.1 entry is probably a problem because NM uses dnsmasq by default and /etc/resolv.conf is then set to 127.0.1.1. I had a look, and network-manager recommends dnsmasq-base, which I don't have installed. Thanks to all for your help! Teresa and Junior -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53967607.4010...@gmail.com
Re: MPD on localhost won't work if there's no Wifi!?
On Lu, 09 iun 14, 23:05:43, Teresa e Junior wrote: I believe it's got something to do with NetworkManager, because mpc started working as soon as I run: $ sudo service network-manager stop And then I run this, and while trying to connect, or later if connecting fails, mpc won't work again: $ sudo service network-manager start The version of NetworkManager installed is 0.9.4.0-10 on wheezy. I believe NM kind of advertises to the system if there is a connection available. As an example, if configured as such, Claws Mail will only check for emails based on information passed by NetworkManager. As far as I can tell mpc is low-level enough to not care about what Network Manager advertises. I'm suspecting it does have something to do with DNS, so I'd suggest you pick a name for your machine and make sure you adjust your configs as follows (assuming your machine's name is 'mpdserver'): /etc/hostname: mpdserver /etc/hosts: 127.0.0.1 localhost 127.0.1.1 mpdserver (you can also use the lan IP here if it is fixed and enabling the IPv6 entries could also help) mpd.conf: bind_to_address localhost If you make all these changes it's probably a good idea to reboot. If mpc still can't connect please post the output of: getent hosts localhost getent hosts mpdserver # or whatever you named it netstat -plant | grep mpd with and without Network Manager running. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: MPD on localhost won't work if there's no Wifi!?
Hi. On Mon, 09 Jun 2014 01:23:43 -0400 Teresa e Junior teresaejun...@gmail.com wrote: I have asked for help at http://forum.musicpd.org/, but they said something is not right in my network, and I believe that could be actually the case. Your network configuration may be the cause of this. Can you please run mpc like this, and show the result: strace -e trace=network mpc Also, you can try adding the following to your mpd.conf to workaround this problem: bind_to_address /run/mpd/socket Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140609095331.b855ede7c584757e5fbe3...@gmail.com
