minidlna crashes on boot when no active network connection

[Chris Weiss]

I've used update-rc.d to make sure it is set to start on boot, but upon booting it is never started. There is never any error in the syslog or the minidlna log.

twice now it has also halted the boot process. I did not record the exact text, but it clearly is complaining that there is no network. It seems to only complain on stderr and not in the log file. My network normally does not come up until just after the login screen shows, when I see the network manager balloon telling about it.

in the conf file I have log_level=debug and network_interface= is commented out.

in /etc/default/minidlna I have START_DAEMON="yes", and OPTS is empty, as default, and I've set the user to the one that "owns" the media files.

after booted and logged in, "service minidlna start" always works.

minidlna version 1.024+dfsg-1 on 12.10 beta. I have not run it on older releases.

[Assaf Shachar (asaf60)]

I can confirm this on 12.04. the problem is indeed related to the network. I have a wifi connection and if I run it without a network connection, it fails to start.Moving the init script to a higher id in the rc init process doesn't seem to work either.
The solution I found is to move the init to upstart as you can tell it to wait until network is up. So I wrote really simple upstart script and I would have put it somewhere if anybody is interesting. But this require a change in the package so the package maintainers should really put it there or write their own.
I would be glad to share this solution....

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Assaf Shachar (asaf60)]

Attached the minidlna.conf upstart init file.
Here is how to use it:

First You need to copy it to /etc/init/
cp minidlna.conf /etc/init/

Then you need to remove minidlna from the old systemv init system by typing:
sudo update-rc.d -f minidlna remove

now you need to symlink the upstart script to /etc/init.d/ like these:

cd /etc/init.d/
sudo ln -s /lib/init/upstart-job minidlna

now you can check that it works by typing

$ sudo service minidlna start
minidlna start/running, process 8369

$ sudo service minidlna stop
minidlna stop/waiting

$ sudo initctl start minidlna
minidlna start/running, process 8417

$ initctl status minidlna
minidlna start/running, process 8417

If you get these work then you good to go.

Disclaimer: I'm not an upstart expert but theses has worked for me and minidlna is up and running after boot.
Hope these helps.

[Chris Weiss (cweiss)]

that certainly helps, but it's only partially a fix. local only operation offline is not possible. yes, one could just directly connect to the media files, but then you's have 2 databases to handle instead of just one.

[Bib (bybeu)]

@ Ray DeCampo
I was driven to your workaround here http://labnotes.decampo.org/2012/12/ubuntu-1210-minidlna-on-boot.html?m=1 by a gentle guy in french ubuntu forum.

Thanks to you all, my minidlna now starts on boot (12.04)

[Bib (bybeu)]

PS: my pc has network configured with static dhcp (wired), if this ever helps a dev.

[kapetr (kapetr)]

Hello, I had report this Bug too - 1236031 - (is seems to be the same problem) - but maybe some questions are still open.

- is this Bug not in minidlna itself ? Why requires minidlna IP address to be set (why do not allow to BIND to ANY address)?
- does the solution with upstart serve also down/up of net device(s) ? Should not be minidlna started by /etc/network/if-up.d scripts ?

[Chris Weiss (cweiss)]

kapetr, the bug is posted on the minidlna package. maybe it's due to a compile option, or an ubuntu patch, I don't know. etiquette is to post the bug on the package and let the package maintainer either fix it or post the bug upstream. though it seems that the maintainer may no longer be active, so I don't know where that leaves us.

[Florian W. (florian-will)]

> - is this Bug not in minidlna itself ? Why requires minidlna IP
> address to be set (why do not allow to BIND to ANY address)?

I think this is because minidlna does not only listen on some interface & port number, it also needs to send out SSDP packets (multicast) on relevant network interfaces. So there's a requirement to determine network interfaces where minidlna is supposed to listen to for clients and send out broadcasts (on startup and in regular intervals) through those interfaces so UPnP clients in that network can auto-discover the minidlna server as soon as it comes up.

As I understand it, there have been a few improvements in this area by the upstream minidlna developer. I haven't tested it because my network config from the POV of my minidlna serving machine is 100% static, but it sounds like minidlna is now supposed to support dynamic changes of network interfaces (including cases like no active network connection and new connections coming up at runtime). Some of the changes are in 1.1.2 (the minidlna version currently in trusty backports) and some of them are in 1.1.3 (released only 10 days ago, not in Ubuntu yet, probably expect it by 14.10 the earliest).

Did anyone test to see if this bug is solved for them using the 1.1.2 version in Trusty backports?

[kapetr (kapetr)]

Thanks <Florian> very much for detailed explanation.

[Florian W. (florian-will)]

A debian user confirmed this is fixed in 1.1.2. So this bug only affects saucy and precise. :-)

[Florian W. (florian-will)]

As I stated above, this should be fixed in recent minidlna releases, so I close this bug now. If this still happens on Ubuntu 14.04 (Trusty) or newer releases, please reopen the bug report.