Hello! I've installed last available minidlna for amd64 platform. If I start minidlna then it fails: # systemctl start minidlna.service Job for minidlna.service failed. See 'systemctl status minidlna.service' and 'journalctl -xn' for details. There are messages in logs: Sep 05 22:20:59 srv systemd[1]: Starting MiniDLNA is a DLNA/UPnP-AV server software... Sep 05 22:20:59 srv minidlnad[7292]: utils.c:271: warn: make_dir: cannot create directory '/var/run/minidlna' Sep 05 22:20:59 srv minidlnad[7292]: minidlna.c:447: error: Unable to create pidfile directory: /var/run/minidlna/minidlna.pid It fails to create directory because minidlna run as separate user minidlna. Please consider option -S for minidlnad. That option for systemd: -S changes behaviour for systemd With that option it is possible (I think) to remove syslog.target from After= section in minidlna.service file. Thank you.
It is possible to add file to /etc/tmpfiles.d containing line like that: d /run/minidlna 0755 minidlna minidlna - This will create directory for minidlna.
It seems like minidlna supports systemd (option -S) and it is not required to specify Type=forking and PIDFile=... in minidlna.service, but minidlna always creates pid file.
Please don't CC maintainers, just wait for bug-wranglers to assign.
Hello Dmitry, can you please check if the new version works as expected, i've modified +*minidlna-1.1.0-r3 (05 Sep 2013) + + 05 Sep 2013; Michael Weber <xmw@gentoo.org> +files/minidlna-1.1.0-r3.initd, + +files/minidlna-1.1.0-r3.service, +minidlna-1.1.0-r3.ebuild: + Revbump to fix systemd support (thanks Dmitry, bug 483780).Revbump to fix + systemd support (thanks Dmitry, bug 483780). + --- files/minidlna-1.1.0.service 2013-05-12 00:19:45.000000000 +0200 +++ files/minidlna-1.1.0-r3.service 2013-09-05 22:21:04.024389381 +0200 @@ -5,9 +5,7 @@ [Service] User=minidlna Group=minidlna -Type=forking -PIDFile=/var/run/minidlna/minidlna.pid -ExecStart=/usr/sbin/minidlnad -f /etc/minidlna.conf -P /var/run/minidlna/minidlna.pid +ExecStart=/usr/sbin/minidlnad -f /etc/minidlna.conf -P /run/minidlna/minidlna.pid -S [Install] WantedBy=multi-user.target --- minidlna-1.1.0-r2.ebuild 2013-06-25 21:47:43.511712234 +0200 +++ minidlna-1.1.0-r3.ebuild 2013-09-05 22:25:35.000000000 +0200 @@ -65,8 +65,10 @@ doins ${PN}.conf newconfd "${FILESDIR}"/${PN}-1.0.25.confd ${PN} - newinitd "${FILESDIR}"/${PN}-1.1.0.initd ${PN} - systemd_newunit "${FILESDIR}"/${PN}-1.1.0.service ${PN}.service + newinitd "${FILESDIR}"/${PF}.initd ${PN} + systemd_newunit "${FILESDIR}"/${PF}.service ${PN}.service + echo "d /run/${PN} 0755 ${PN} ${PN} -" > "${T}"/${PN}.conf + systemd_dotmpfilesd "${T}"/${PN}.conf dodir /var/{lib,log}/${PN} fowners ${PN}:${PN} /var/{lib,log}/${PN}
Thank you! This works fine if I start/stop service manually. But I can't fix problem at startup. If I enable service 'systemctl enable minidlna' then it [minidlna] will fail during boot (after restart of computer): minidlna.c:528: No MAC address found. Falling back to generic UUID. minidlna.c:927: fatal: No IP address automatically detected! systemd[1]: Unit minidlna.service entered failed state. I have tried to add After=network-online.target to minidlna.service but this doesn't help. Thank you!
Temporary solution is add line 'ExecStartPre=/bin/sleep 10' to minidlna.service.
I hand this over to systemd maintainers for solving the dependency issue. I cannot test it on my environment. Thanks The .service file is at http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/minidlna/files/minidlna-1.1.0-r3.service?view=log
(In reply to Dmitry from comment #5) What do you use to configure your network interfaces?
I'm new to Gentoo and I have installed dhcpcd to make network working on my home mini media server.
Maybe try adding After=network.target; that will at least ensure that dhcpcd is started before minidlna; it still might not have the interface configured, however. Support for network-online.target seems pretty spotty at this time.
After=network.target already specified and it isn't help. It seems network-online.target is intended for handle moment when network becomes working.
Ok, ons solution would be to change dhcpcd.service work in forking mode and pass it the --waitip command line option. -w, --waitip Wait for an address to be assigned before forking to the background. It should also have Before=network-online.target added.
Can you try replacing dhcpcd.service with the unit below? [Unit] Description=Lightweight DHCP client daemon Wants=network.target Before=network.target network-online.target [Service] # Pass --waitip so we can provide a sync point for network-online.target. # Requres forking mode. ExecStart=/sbin/dhcpcd --quiet --waitip Type=forking PIDFile=/var/run/dhcpcd.pid [Install] WantedBy=multi-user.target
How would that work when networking is unavailable (e.g. the cable is disconnected)?
(In reply to Michał Górny from comment #14) > How would that work when networking is unavailable (e.g. the cable is > disconnected)? Good question. I'm not sure how --waitpid works if it cannot find a working connection. Worst case, it times out after 90 seconds (systemd's limit). We might want to add this as an alternative unit (dhcpcd-wait.service) so that we don't introduce delays for everybody. Of course, ideally software would respond to network configuration changes. ^_^
