Debian Bug report logs - #534504
mediatomb: Daemon starts up too early in the boot process; interface not found

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Iain Lane <laney@ubuntu.com>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: mediatomb: Daemon starts up too early in the boot process; interface not found

Date: Wed, 24 Jun 2009 23:39:37 +0100

Package: mediatomb
Version: 0.12.0~svn2018-3ubuntu2
Severity: important

Hi,

I've installed mediatomb on my PC but it doesn't launch at boot because
the interface I've specified in the config file with <interface> doesn't
exist at the point when the program is ran. The following is present in
the log file:

2009-06-24 09:18:51   ERROR: Could not determine interface address:
Cannot assign requested address
2009-06-24 09:18:51   ERROR: Could not find interface: eth3

It works if I restart via the init script after the machine is booted.

I tried moving the script later in the sequence by increasing the place
in the init ordering but this had no effect.

Iain

-- System Information:
Debian Release: squeeze/sid
  APT prefers karmic-updates
  APT policy: (500, 'karmic-updates'), (500, 'karmic-security'), (500, 'karmic-proposed'), (500, 'karmic-backports'), (500, 'karmic')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-9-generic (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mediatomb depends on:
ii  epiphan 2.26.1-0ubuntu2                  Intuitive GNOME web browser - Geck
ii  firefox 3.0.11+build2+nobinonly-0ubuntu2 meta package for the popular mozil
ii  firefox 3.0.11+build2+nobinonly-0ubuntu2 safe and easy web browser from Moz
ii  lynx-cu 2.8.7pre5-1                      Text-mode WWW Browser with NLS sup
ii  mediato 0.12.0~svn2018-3ubuntu2          UPnP MediaServer (daemon package)
ii  opera [ 9.50-20080422.2                  The Opera Web Browser
ii  w3m [ww 0.5.2-2build1                    WWW browsable pager with excellent

mediatomb recommends no packages.

mediatomb suggests no packages.

-- no debconf information

Message #10 received at 534504@bugs.debian.org (full text, mbox, reply):

From: Iain Lane <laney@ubuntu.com>

To: control@bugs.debian.org

Cc: 534504@bugs.debian.org

Subject: found 534504 in 0.12~svn2018-3

Date: Sat, 27 Jun 2009 10:50:47 +0100

# Automatically generated email from bts, devscripts version 2.10.35lenny3
#also happens in sid
found 534504 0.12~svn2018-3

Message #17 received at 534504@bugs.debian.org (full text, mbox, reply):

From: Bruce LaZerte <bdl@fwr.on.ca>

To: 534504@bugs.debian.org

Subject: Problem may be Network-Manager

Date: Sun, 12 Jul 2009 11:19:19 -0400

Similar problem here. eth0 is managed by Network Manager, so it's not 
brought up until the user is logged in, long after /etc/init.d/mediatomb 
runs.

Possible solutions:
1) Manage eth0 with /etc/network/interfaces, bypassing Network-Manager.
/etc/init.d/ifupdown runs before /etc/init.d/mediatomb

2) Startup Mediatomb as a user. Change /etc/default/mediatomb to
nostart=yes, and run as a user, "mediatomb --daemon --logfile
/home/user/.mediatomb/mediatomb.log" etc.

3) Have a user "sudo /etc/init.d/mediatomb start" after they've logged
in.

Options 2) and 3) can both be automated, but both depend upon the user 
being logged in for eth0 to be available. Use option 1) if you want the 
media server to be always on no matter who is logged in.

BDL

Message #22 received at 534504@bugs.debian.org (full text, mbox, reply):

From: Iain Lane <laney@ubuntu.com>

To: 534504@bugs.debian.org

Date: Thu, 30 Jul 2009 21:50:19 +0100

/etc/network/interfaces was my workaround too. My connection was  
managed as a systemwide connection by NM. I'm not sure when it comes  
up in this case. I guess mediatomb could keep retrying or block on  
some signal if one exists in this case.

Message #27 received at 534504@bugs.debian.org (full text, mbox, reply):

From: Eric Lavarde <bugs.debian.nospam@lavar.de>

To: Debian Bug Tracking System <534504@bugs.debian.org>

Subject: [patch] ifupdown integration of mediatomb

Date: Sun, 24 Jan 2010 13:55:41 +0100

[Message part 1 (text/plain, inline)]

Package: mediatomb
Followup-For: Bug #534504

Hello,

to solve the problem described by other persons, I've created two small
scripts that start and stop mediatomb when the interfaces are being
brought up and down. There is also a diff file for
/etc/default/mediatomb that adds a variable DELAYED (yes/no) to
disable/enable those small scripts.

Few remarks:

1. the current default is DELAYED=yes, which enables the script. It
doesn't really hurt as mediatomb is restarted, and should work in all
situations (with and withou NetworkManager).

2. I'm not sure I correctly understood the meaning of the "INTERFACE"
variable (mine is empty), so my check might be incorrect as I only restart/stop
if the interface given by INTERFACE is being stopped/started
($IFACE = $INTERFACE). Someone with more knowledge of mediatomb's internas
might want to check if this is the right decision.

3. if INTERFACE=lo, then the scripts do something if and only if the 'lo'
interface is brought up or down, again, it might not be the right logic.

4. the attached tar file contains the files and diff with correct
relative position (don't unpack in root direcotry unless it's what you want
to do!).

Hope this helps,
Eric

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-bpo.1-686 (SMP w/2 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages mediatomb depends on:
ii  iceweasel [www-browser] 3.0.6-3          lightweight web browser based on M
ii  konqueror [www-browser] 4:3.5.9.dfsg.1-6 KDE's advanced file manager, web b
ii  mediatomb-daemon        0.11.0-3         UPnP MediaServer (daemon package)

mediatomb recommends no packages.

mediatomb suggests no packages.

-- no debconf information

[mediatomb_ifnm.tgz (application/x-gzip, attachment)]

Message #32 received at 534504@bugs.debian.org (full text, mbox, reply):

From: Reinhard Tartler <siretart@tauware.de>

To: Eric Lavarde <bugs.debian.nospam@lavar.de>

Cc: 534504@bugs.debian.org

Subject: Re: Bug#534504: [patch] ifupdown integration of mediatomb

Date: Sun, 24 Jan 2010 18:48:51 +0100

On So, Jan 24, 2010 at 13:55:41 (CET), Eric Lavarde wrote:

> Package: mediatomb
> Followup-For: Bug #534504
>
> Hello,
>
> to solve the problem described by other persons, I've created two small
> scripts that start and stop mediatomb when the interfaces are being
> brought up and down.

I understand from the context of the bug that the issue seems to be that
mediatomb must not be started before the network interface is up and
running. Why can't this be fixed be changing the initscript ordering?

> There is also a diff file for /etc/default/mediatomb that adds a
> variable DELAYED (yes/no) to disable/enable those small scripts.

The race condition is present on *all* systems, so no need to make this
fix configurable.

> Few remarks:
>
> 1. the current default is DELAYED=yes, which enables the script. It
> doesn't really hurt as mediatomb is restarted, and should work in all
> situations (with and withou NetworkManager).

What about the case that a system has 2 interfaces and mediatomb is
serving to both interfaces at the same time: Restarting one interface is
likely to disconnect users connected via that interface, but would this
affect users via the second interface as well?

> 2. I'm not sure I correctly understood the meaning of the "INTERFACE"
> variable (mine is empty), so my check might be incorrect as I only
> restart/stop if the interface given by INTERFACE is being
> stopped/started ($IFACE = $INTERFACE). Someone with more knowledge of
> mediatomb's internas might want to check if this is the right
> decision.

I guess this is a saftey guard to avoid unnecessary restarts if
mediatomb is configured to serve only on one specific interface and
other interfaces are restarted. Which seems to suggest an answer to my
previous question.

> 3. if INTERFACE=lo, then the scripts do something if and only if the 'lo'
> interface is brought up or down, again, it might not be the right logic.

what do they do exactly?

> 4. the attached tar file contains the files and diff with correct
> relative position (don't unpack in root direcotry unless it's what you want
> to do!).

I see that your if-updown scripts call the init script. That means that
depending on the context the init script is called, it behaves
differently. I find this a bit odd.

How about dumping the init script altogether and implement starting and
stopping mediatomb solely from if-updown scripts? This way there was no
need for the DELAYED=yes flag and the race condition would be avoided as
well.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Message #37 received at 534504@bugs.debian.org (full text, mbox, reply):

From: Andres Mejia <mcitadel@gmail.com>

To: 534504@bugs.debian.org

Subject: Re: Bug#534504: [patch] ifupdown integration of mediatomb

Date: Wed, 3 Mar 2010 01:27:42 -0500

On Sunday 24 January 2010 12:48:51 Reinhard Tartler wrote:
> On So, Jan 24, 2010 at 13:55:41 (CET), Eric Lavarde wrote:
> > Package: mediatomb
> > Followup-For: Bug #534504
> >
> > Hello,
> >
> > to solve the problem described by other persons, I've created two small
> > scripts that start and stop mediatomb when the interfaces are being
> > brought up and down.
> 
> I understand from the context of the bug that the issue seems to be that
> mediatomb must not be started before the network interface is up and
> running. Why can't this be fixed be changing the initscript ordering?
> 
> > There is also a diff file for /etc/default/mediatomb that adds a
> > variable DELAYED (yes/no) to disable/enable those small scripts.
> 
> The race condition is present on *all* systems, so no need to make this
> fix configurable.
> 
> > Few remarks:
> >
> > 1. the current default is DELAYED=yes, which enables the script. It
> > doesn't really hurt as mediatomb is restarted, and should work in all
> > situations (with and withou NetworkManager).
> 
> What about the case that a system has 2 interfaces and mediatomb is
> serving to both interfaces at the same time: Restarting one interface is
> likely to disconnect users connected via that interface, but would this
> affect users via the second interface as well?
> 
> > 2. I'm not sure I correctly understood the meaning of the "INTERFACE"
> > variable (mine is empty), so my check might be incorrect as I only
> > restart/stop if the interface given by INTERFACE is being
> > stopped/started ($IFACE = $INTERFACE). Someone with more knowledge of
> > mediatomb's internas might want to check if this is the right
> > decision.
> 
> I guess this is a saftey guard to avoid unnecessary restarts if
> mediatomb is configured to serve only on one specific interface and
> other interfaces are restarted. Which seems to suggest an answer to my
> previous question.
> 
> > 3. if INTERFACE=lo, then the scripts do something if and only if the 'lo'
> > interface is brought up or down, again, it might not be the right logic.
> 
> what do they do exactly?
> 
> > 4. the attached tar file contains the files and diff with correct
> > relative position (don't unpack in root direcotry unless it's what you
> > want to do!).
> 
> I see that your if-updown scripts call the init script. That means that
> depending on the context the init script is called, it behaves
> differently. I find this a bit odd.
> 
> How about dumping the init script altogether and implement starting and
> stopping mediatomb solely from if-updown scripts? This way there was no
> need for the DELAYED=yes flag and the race condition would be avoided as
> well.
> 

Simplest thing to do I think would be to have the if-updown scripts just run 
the mediatomb init script. 

-- 
Regards,
Andres

Message #42 received at 534504@bugs.debian.org (full text, mbox, reply):

From: Daniel van Vugt <vanvugt@gmail.com>

To: 534504@bugs.debian.org

Subject: Fix for upstart/Ubuntu systems

Date: Wed, 20 Apr 2011 13:46:56 +0800

https://bugs.launchpad.net/ubuntu/+source/mediatomb/+bug/212441/comments/19

Here's a patch for this bug I've been using on Ubuntu. Note that it uses 
upstart, so probably won't solve the problem for pure Debian.

Still, it would be nice if we could push this patch or something like it 
into the Debian source rather than relying on downstream Ubuntu patching.

- Daniel

Message #47 received at 534504-done@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 503677-done@bugs.debian.org,509918-done@bugs.debian.org,534504-done@bugs.debian.org,542627-done@bugs.debian.org,555594-done@bugs.debian.org,562858-done@bugs.debian.org,562860-done@bugs.debian.org,572701-done@bugs.debian.org,589208-done@bugs.debian.org,600025-done@bugs.debian.org,604960-done@bugs.debian.org,606804-done@bugs.debian.org,624921-done@bugs.debian.org,631046-done@bugs.debian.org,633803-done@bugs.debian.org,642578-done@bugs.debian.org,652534-done@bugs.debian.org,661149-done@bugs.debian.org,631784-done@bugs.debian.org,

Cc: mediatomb@packages.debian.org, mediatomb@packages.qa.debian.org

Subject: Bug#662020: Removed package(s) from unstable

Date: Sat, 03 Mar 2012 19:26:55 +0000

Version: 0.12.1-2+rm

Dear submitter,

as the package mediatomb has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see http://bugs.debian.org/662020

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@debian.org.

Debian distribution maintenance software
pp.
Luca Falavigna (the ftpmaster behind the curtain)

Message #54 received at 534504@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Iain Lane <laney@ubuntu.com>, 534504@bugs.debian.org

Subject: Re: Bug#534504: mediatomb: Daemon starts up too early in the boot process; interface not found

Date: Sun, 28 Oct 2012 02:20:05 +0100

Hi!

On Wed, 2009-06-24 at 23:39:37 +0100, Iain Lane wrote:
> Package: mediatomb
> Version: 0.12.0~svn2018-3ubuntu2
> Severity: important
> 
> I've installed mediatomb on my PC but it doesn't launch at boot because
> the interface I've specified in the config file with <interface> doesn't
> exist at the point when the program is ran. The following is present in
> the log file:
> 
> 2009-06-24 09:18:51   ERROR: Could not determine interface address:
> Cannot assign requested address
> 2009-06-24 09:18:51   ERROR: Could not find interface: eth3
> 
> It works if I restart via the init script after the machine is booted.

The real problem here is that it seems mediatomb unneedingly forces
itself to know the IP of an (outbound) interface at startup and refuses
to work otherwise. Here's a quick (and possibly bogus) analysis of the
code involved:

,---
src/tools.cc (interfaceToIP):

  Returns nil and logs an error if it cannot retrieve the IP of the
  interface (which I guess is more or less fine, although the output
  is annoying).

src/server.cc (Server::upnp_init):

  Calls interfaceToIP(iface) if there's no explicit IP specified to the
  daemon, and aborts if one cannot be retrieved, otherwise calls
  UpnpInit() with the IP, port, etc. Then calls UpnpGetServerIpAddress()
  again to retrieve the found address if the IP was not valid (which
  cannot be because we've bailed out before). It also tries to start
  sending UPnP advertisements.

tombupnp/upnp/src/api/upnpapi.c (UpnpInit):

  If HostIP is !NULL it uses that as LOCAL_HOST, otherweise it tries
  again to retrieve a local host IP and uses that instead as LOCAL_HOST
  (all this by crawling through the physical interfaces).
`---

The correct and proper fix seems to me, would be to:

  1) If either no explicit interface or IP has been specified on the
     command-line, use getaddrinfo with node == NULL and
     hints.ai_flags == AI_PASSIVE, so that we get the INADDR_ANY.
  2) Bind to that address for listening.
  3) Move the IP retrieval and interface sieve for when sending
     outbound advertisement messages, and handle the case of no
     interfaces being UP or only loopback as non-errors.

I'm not sure how much work that would imply though, but a media server
like minidlna is doing something like that (not to mention the myriad
of other server software around), and works just fine w/o an initially
setup (outbound) interface.

(BTW, while digging I noticed there's an embedded fork of libupnp,
which from a quick look does not seem to handle this gracefully
either...)

regards,
guillem

Message #59 received at 534504@bugs.debian.org (full text, mbox, reply):

From: Gregory Shimansky <gshimansky@gmail.com>

To: 534504@bugs.debian.org

Subject: Re: Bug#534504: mediatomb: Daemon starts up too early in the boot process; interface not found

Date: Fri, 9 Jan 2015 23:27:48 +0300

[Message part 1 (text/plain, inline)]

I just had a fresh install of Debian 7.7.0, and had the same problem with
mediatomb. After I configured INTEFACE to eth0 in /etc/default/mediatomb I
got this error in /var/log/mediatomb.log at startup:

2015-01-09 22:46:08   ERROR: Could not determine interface address: Cannot
assign requested address
2015-01-09 22:46:08   ERROR: Could not find interface: eth0

The problem appears to be in minissdpd service. For some reason it was
added to startup together with mediatomb. I don't know which dependency
pulled this service and why it was enabled by default. After removing
minissdpd package I have meditomb running just fine at startup.

-- 
Gregory

[Message part 2 (text/html, inline)]

Send a report that this bug log contains spam.