Hide Forgot
Created attachment 807233 [details] patch to specify that maradns daemons start after network.target Description of problem: The systemd service files for maradns do not specify that it should start after network.target. As a result, it may start before the network interfaces come up. This causes errors since it cannot bind its sockets. The current service files say "Requires=network.target". They should also say "After=network.target". Version-Release number of selected component (if applicable): maradns-2.0.07c-1.fc20 How reproducible: Boot up system with maradns enabled, and the daemon may fail to start if systemd runs it before bringing up the network. Steps to Reproduce: 1. Boot up a system with maradns enabled. 2. 3. Actual results: It fails to start. It give an error message about being unable to bind to the address. Systemd tries to start it many times and then gives up. Expected results: The maradns daemon should start properly. Additional info:
Sounds good on principle, but network.target is not what you expect here. See: http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ I think that better way should be adding After=NetworkManager-wait-online.service. Notice After, but not Require. This way sysadmin can enable NM-w-o if it needed in his config. What do you think about my solution?
I'm afraid that won't work. I don't use the NetworkManager service at my site. I believe that "network.target" is the standard solution for this problem. For example: [root@ti19 ajs]# uname -a Linux ti19 3.10.11-200.fc19.x86_64 #1 SMP Mon Sep 9 13:03:01 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [root@ti19 ajs]# grep 'After=.*network\.target' /usr/lib/systemd/system/*.service | wc -l 57 Compare that to: [root@ti19 ajs]# grep 'After=.*NetworkManager' /usr/lib/systemd/system/*.service /usr/lib/systemd/system/xinetd.service:After=syslog.target network.target NetworkManager-wait-online.service Regards, Andy
Andy, have you read the URL I linked? I can add After=network.service as a workaround, too. After=network.target won't do, I think. Let me ask upstream.
Yes, I read it. But let's face it, services like maradns tend to run on servers with static IP configs. In that case, network.target should work just fine. That will work for my environment. Please add After=network.target. Does After=NetworkManager-wait-online.service work on systems that are not running NetworkManager? Maybe we need both. Thanks, Andy
To clarify further: I am not sure how other people configure their servers, but at my site, we use network.service instead of NetworkManager.service. So we have: bash-4.2$ systemctl --after list-dependencies network.target network.target ├─firewall.service └─network.service I think that's adequate for bringing up the interfaces and assigning IP addresses. Maybe I am confused, but it seems to work OK for our other daemons. The network.service LSB script calls ifup on all the interfaces. I think brings up the interface fully before exiting. So I think your concerns are relevant only for systems using NetworkManager. I don't know whether people are using NetworkManager on server systems with static configs. Are they? Thanks, Andy
[220216] <tomegun> zdzichuBG: you probably want network-online.target (not the NM-specific one) That's seem to be the best solution. I'll think about it tomorrow again :)
It seems that network-online.target is not used very much. Please compare to other dns servers such as unbound, nsd, powerdns, and bind. I see that unbound uses After=network.target. I'm not sure about the others. For my purposes, network.target works well. I suspect that network-online.target will not work, since it does not seem to be ordered after network.target. The only thing I see that uses network-online.target is kdump.service, but it also says it must be after network.target. I really think network.target should be the answer. Regards, Andy
network-online.target is a relatively new addition. But it is the way to go. See http://www.freedesktop.org/software/systemd/man/systemd.special.html (Or alternatively "systemctl help network-online.target".)
I am sure you must be right, but I must confess that I don't understand how ordering after network-online.target helps in practice. On my Fedora 19 system, I see this: bash-4.2$ uname -r 3.10.11-200.fc19.x86_64 bash-4.2$ systemctl -p After show network-online.target After= So by ordering after network-online.target, what is actually accomplished? Where is it specified that this target is satisfied only after the network is up? I'm afraid I didn't understand the language in the man page. Perhaps I do not understand systemd sufficiently well. I just searched the systemd-208 source code, and I see that network mounts pull this in, but I don't see how that accomplishes anything. Thanks for any pointers that would help me to understand this better.
> Where is it specified that this target is satisfied only after the network is up? % systemctl list-dependencies network-online.target network-online.target └─NetworkManager-wait-online.service That solves the problem on systems using NetworkManager. I don't think there is similar hookup for systems with static network.service. Maybe when enabling network.service, admin is supposed to hook it into network-online.target manually? So, my plan is: 1) add After=network-online.target; that's the proper solution 2) add After=network.service: not the .target, which means nothing peculiar. Adding this after will order maradns after network.service IF the network.service is enabled, and won't matter in other cases. Better solution would be to patch MaraDNS to use IP_FREEBIND to bind to IPs before they exist. I won't go this route, as upstream is rather hostile to external patches.
I guess that should work, although it seems unusual to me to add network.service to the mix. Many existing systemd units refer to network.target, but I don't see network.service referenced anywhere except in arp-ethers.service. The existing maradns unit file already says "Requires=network.target". It seems to me that the simplest, cleanest, and most consistent patch is to add "After=network.target". I can't see why it's helpful to introduce network.service. But it's up to you. I'm no systemd expert. I can always patch things to work at my site (as I have done already).
Ugh, you are right -- network.target is inadequate. I just rebooted, and both unbound and maradns failed to start. Here is the unbound error: Oct 06 11:09:42 ti24 unbound[1401]: Oct 06 11:09:41 unbound[1401:0] error: can't bind socket: Cannot assign requested address Oct 06 11:09:42 ti24 unbound[1401]: Oct 06 11:09:41 unbound[1401:0] debug: failed address 192.168.78.1 port 53 Oct 06 11:09:42 ti24 unbound[1401]: Oct 06 11:09:41 unbound[1401:0] fatal error: could not open ports And from maradns: Oct 06 11:09:39 ti24 maradns[1152]: Fatal error: Problem binding to port 53. Oct 06 11:09:39 ti24 maradns[1152]: System said: Cannot assign requested address This was after network.service completed. So I guess "ifup" exits before the address actually becomes bindable. If network-online.target can actually solve this problem, then that will be great. But it does not appear to me that "network-online.target" is of any help on my Fedora 19 system, since "systemctl show network-online.target" does not show any Before or After dependencies. I may have to hack some "sleep" backoff timers into those unit files. Is there any better solution?
Oops, please ignore the previous comment #12. I believe those problems were caused by errors in my configuration files. As far as I know, the addresses should be bindable when network.service finishes.
maradns-2.0.07c-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/maradns-2.0.07c-2.fc20
Package maradns-2.0.07c-2.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing maradns-2.0.07c-2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-19071/maradns-2.0.07c-2.fc20 then log in and leave karma (feedback).
maradns-2.0.07c-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.