You are not logged in.
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[401]: [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)
Offline
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 ...
Offline
Will check it Sir in an hour I hope.
Offline
Unfortunately it is not working, no matter if I put there 'multi-user.target' or 'net-auto-wired.target'.
Offline
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.
Offline
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 dhcp@eth0.service to use DHCP that way (on eth0)
Offline
I did not see this as being solved, so I dredged up this old thread.
szebenyib quote:
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.
Pudge
Offline
Many thanks Sir, I will try that out, as it is still not working.
Offline
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!
Offline
(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.
/etc/conf.d/network
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
netmask=24
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 8.8.8.8
If you cannot ping google.com but can ping 8.8.8.8 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.
HTH
Pudge
Offline
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
/etc/resolv.conf.head
# Google nameservers
nameserver 8.8.8.8
nameserver 8.8.4.4
as stated here in the wiki.
Thank you for your guidelines and patience!
Regards,
szebenyib
Offline
You are welcome, glad I could help.
Pudge
Offline
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 dhcpcd@enp4s0.service
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
Read it before posting http://www.catb.org/esr/faqs/smart-questions.html
Ruby gems repository done right https://bbs.archlinux.org/viewtopic.php?id=182729
Fast initramfs generator with security in mind https://wiki.archlinux.org/index.php/Booster
Offline
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.
Offline