I am using an up-to-date system as of 2012-11-13. The problem is that minidlna fails to start on boot:
minidlna.service - minidlna server Loaded: loaded (/usr/lib/systemd/system/minidlna.service; enabled) Active: failed (Result: exit-code) since Tue, 2012-11-13 07:53:55 CET; 1h 33min ago Process: 401 ExecStart=/usr/sbin/minidlna -P /var/run/minidlna/minidlna.pid (code=exited, status=255) CGroup: name=systemd:/system/minidlna.service Nov 13 07:53:59 earth minidlna: [2012/11/13 07:53:54] minidlna.c:754: fatal: No IP address automatically detected!
So I guess it has to do something with the network, I am using DHCP, with systemd + net-auto-wired.service.
I have found this: https://ask.fedoraproject.org/question/ … r-dhcp-has
They have solved the problem by changing the after part in the unit by adding: dbus-org.freedesktop.NetworkManager.target
Since I do not use networkmanager, this is not an option for me. The current, unmanipulated state of the minidlna unit is:
[Unit] Description=minidlna server After=network.target [Service] Type=forking User=nobody ExecStart=/usr/sbin/minidlna -P /var/run/minidlna/minidlna.pid PIDFile=/var/run/minidlna/minidlna.pid [Install] WantedBy=multi-user.target
What I have noticed is that it refers to a network.target in the after section, but it seems to me that I don't have one.
I only have:
UNIT LOAD ACTIVE SUB JOB DESCRIPTION basic.target loaded active active Basic System cryptsetup.target loaded active active Encrypted Volumes getty.target loaded active active Login Prompts graphical.target loaded active active Graphical Interface local-fs-pre.target loaded active active Local File Systems (Pre) local-fs.target loaded active active Local File Systems multi-user.target loaded active active Multi-User remote-fs.target loaded active active Remote File Systems sockets.target loaded active active Sockets sound.target loaded active active Sound Card swap.target loaded active active Swap sysinit.target loaded active active System Initialization LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. JOB = Pending job for the unit. 12 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'.
Edit: having run the command again with the --all prefix:
Notice: network.target loaded inactive dead Network
UNIT LOAD ACTIVE SUB JOB DESCRIPTION basic.target loaded active active Basic System cryptsetup.target loaded active active Encrypted Volumes emergency.target loaded inactive dead Emergency Mode final.target loaded inactive dead Final Step getty.target loaded active active Login Prompts graphical.target loaded active active Graphical Interface local-fs-pre.target loaded active active Local File Systems (Pre) local-fs.target loaded active active Local File Systems multi-user.target loaded active active Multi-User network.target loaded inactive dead Network nss-lookup.target loaded inactive dead Host and Network Name Lookups nss-user-lookup.target loaded inactive dead User and Group Name Lookups remote-fs.target loaded active active Remote File Systems rescue.target loaded inactive dead Rescue Mode shutdown.target loaded inactive dead Shutdown sockets.target loaded active active Sockets sound.target loaded active active Sound Card swap.target loaded active active Swap sysinit.target loaded active active System Initialization syslog.target loaded inactive dead Syslog umount.target loaded inactive dead Unmount All Filesystems LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. JOB = Pending job for the unit. 21 loaded units listed. To show all installed unit files use 'systemctl list-unit-files'.
My question is what should I add to the after part to make minidlna work upon booting? Wouldn't a graphical.target be an overkill?
Thanks in advance.
Last edited by szebenyib (2012-12-02 16:45:26)
Well as far as I understand it, minidlna needs to connect to the network, when starting up. So your network interfaces must be configured, before starting minidlna. So you must start minidlna After=net-auto-wired.service and After=WhateverYourDHCPServiceIs ...
Will check it Sir in an hour I hope.
Unfortunately it is not working, no matter if I put there 'multi-user.target' or 'net-auto-wired.target'.
Well there is a section about how to handle applications which depend on the network manager in the wiki. But since you don't use the network manager i don't really think, that this will help you. One could write a script, which could be started instead of minidlna, which checks for the network interface(s) to be up and then starts minidlna. But I don't think, that this is the right method to do this, sorry.
Did you disable the network.target? I would first look into why that is disabled and re-enable it ("systemctl enable network.target" I believe). I use the net-auto-wired too and I see the following:
network.target loaded active active Network
Also, are you using a static IP? If not you could try enabling the email@example.com to use DHCP that way (on eth0)
I did not see this as being solved, so I dredged up this old thread.
I am using DHCP, with systemd + net-auto-wired.service.
Edit: having run the command again with the --all prefix:
Notice: network.target loaded inactive dead Network
I was setting up a home file/media server with a base install of Arch Linux. I used the Beginners' Guide and set up a static IP address as it described.
When I installed minidlna, I was experiencing the same problem of minidlna not automatically starting at boot up, and systemctl reporting: Notice: network.target loaded inactive dead Network
Evidently net-auto-wired.service as per the Beginners' Guide isn't quite the optimal unit setup. The key was to get network.target to become: network.target loaded active active Network
I eventually fixed this by
#systemctl stop net-auto-wired.service
#systemctl disable net-auto-wired.service
Then I set up a new systemd service as per the WIKI page Systemd/Services for a Static IP.
I created the /etc/conf.d/network file with my appropriate information. Then I created the /etc/systemd/system/network.service file exactly as is in the WIKI page.
#systemctl enable network.service
Then reboot, and everything worked, network.target was active and minidlna loaded and ran as expected.
The OP was using DHCP with systemd + net-auto-wired.service. Most times minidlna would be installed on a file/media server, which is best served with a Static IP in my opinion.
If you can use a static IP this is a graceful solution. If not, a DHCP solution that properly handles network.target would be needed.
Many thanks Sir, I will try that out, as it is still not working.
Yes it gets minidlna working
(However I cannot acces the internet that way, maybe because of a bad network file. Honestly I have some space to improve my network knowledge.)
I do not think that this is how it should be solved, but this is a solution for the time being, thank you!
(However I cannot access the internet that way, maybe because of a bad network file. Honestly I have some space to improve my network knowledge.)
In the case of the possible bad network file. here is what it expects. First, you need to know the router's IP address. In the following I will assume 192.168.0.1 for the router's IP address.
192.168.0.1 is common for D-Link routers, but it does vary by router manufacturer and model. I believe 192.168.1.1 is common for Linksys.
interface=eth0 # ethernet port to activate, usually eth0
address=192.168.0.110 # IP address you want the minidlna computer to have. the first 3 triads must be the same as the router's IP addr in this case 192.168.0 the fourth triad can be from 5 to 250
broadcast=192.168.0.255 # the first 3 triads must be the same as the router's IP address and the fourth triad should be 255
gateway=192.168.0.1 # the IP address of your router
In a terminal window, enter:
systemctl restart network.service
ping -c5 127.0.0.1
which is localhost. The -c5 means ping 5 times then quit. If you get: 5 packets transmitted, 5 received, 0% packet loss then the ping was successful, which means
that the ethernet port (usually eth0) is active. If this ping is not successful, go back and check the syntax and spelling in both /etc/conf.d/network and /etc/systemd/system/network.service
If the ping is successful:
ping -c5 192.168.0.1
and ping the router.
If you cannot ping the router's IP address, then there is still something wrong in one of the two involved files. or the router's settings need to be changed.
If you can ping the router's IP address successfully and still cannot get to the internet, you probably have DNS server issues.
ping -c5 google.com
ping -c5 184.108.40.206
If you cannot ping google.com but can ping 220.127.116.11 then you have DNS problems, see Arch WIKI resolv.conf
My network is a mixture of DHCP and STATIC IP addresses. In my router, I have the DHCP server enabled to give IP addresses between 192.168.0.10 and 192.168.0.60
this gives the router 50 DHCP addresses to work with which is more that enough for my home network. The rest of the addresses between 192.168.0.61 and 192.168.0.250
can be used as static addresses. Just an example, this can be changed as necessary.
I have finally solved it - thanks to you!
Sorry it took me so long to get back here, but I did not have the time to tamper with my pc recently.
But now it is working I just had to follow your steps and it turned out that I did not have name resolution.
So I just added to
# Google nameservers nameserver 18.104.22.168 nameserver 22.214.171.124
as stated here in the wiki.
Thank you for your guidelines and patience!
You are welcome, glad I could help.
I had the same startup issue with minidlna. Minidnla service fails to start on boot and I see "fatal: No IP address automatically detected!" is logs. I had to restart it manually with
# systectl restart minidlna
I do not use neither Gnome nor NetworkManager applet so adding "dbus-org.freedesktop.NetworkManager.target" to service config file is not an option for me.
For some reason minidlna service started before dhcp client was ready. After some experiments I think I found the reason of it. The problem was that I started dhcpcd incorrectly:
# systemctl enable dhcpcd.service
but after I changed previous command to this one:
# systemctl enable firstname.lastname@example.org
everything works fine (rebooted machine 6 times already). It looks like the interface name (enp4s0) is essential for dhcpcd service, despite the fact I have only 1 network interface.
To find your network interface name just run:
$ ip a
Thanks for posting
This is no longer an issue for me, as I have moved my media collection to nas, but I may test your solution when I'll have time.