Description of problem: Due to all this systemd change overs xinetd does NOT work properly if using hostnames/FQDN in access control. This works fine when xinetd is restarted. The problem appears to be that it is unable to resolve the names due to 1) network not being up, or 2) bind or other resolution not being available. I do not know enough about systemd to even suggest a fix. Sorry. Version-Release number of selected component (if applicable): xinetd-2.3.14-37.fc16.x86_64
Could you please provide your setup so I can reproduce the issue?
Below are my two amanda (amanda_tcp and amanda_udp). They only allow connections from my amanda server. From time to time xinetd gets started before named. Unless I restart xinetd, connections won't work. service amanda { socket_type = stream protocol = tcp wait = no user = amandabackup group = disk server = /usr/sbin/amandad # Configure server_args for the authentication type you will be using, # and the services you wish to allow the amanda server and/or recovery # clients to use. # # Change the -auth= entry to reflect the authentication type you use. # Add amindexd to allow recovery clients to access the index database. # Add amidxtaped to allow recovery clients to access the tape device. server_args = -auth=bsdtcp amdump disable = no only_from = AMANDA_SERVER_FQDN } service amanda { socket_type = dgram protocol = udp wait = yes user = amandabackup group = disk server = /usr/sbin/amandad # Configure server_args for the authentication type you will be using, # and the services you wish to allow the amanda server and/or recovery # clients to use. # # Change the -auth= entry to reflect the authentication type you use. # Add amindexd to allow recovery clients to access the index database. # Add amidxtaped to allow recovery clients to access the tape device. server_args = -auth=bsd amdump disable = no only_from = AMANDA_SERVER_FQDN } If this is not what you meant, please let me know.
> From time to time xinetd gets started before named. I assume this means that xinetd is started via systemd after boot. Is there anything strange in syslog? Or anything strange after typing 'systemctl status network.target' ?
Yes, everything on my system is systemd (although some things are through compatibility - those things that Fedora ships as such). No, nothing else strange. They just seem to be started out of order and it seems that xinetd must cache the ip addresses from the FQDN on startup.
I finally have a clue about what might be going on. Xinetd should start after network.target, which is right, but since bind has its own service file, I think those two are independent and there is no way to ensure that bind starts before everything else that requires it, including xinetd. I'm not sure what exactly the network.target does. Could you please try modifying the 'After' line in xinetd.service, so it looks like this: After=syslog.target network.target bind.service xinetd.service is located in /lib/systemd/system/ I think this might solve your issue.
Fixed in rawhide: http://lists.fedoraproject.org/pipermail/scm-commits/2012-April/770014.html
xinetd-2.3.14-46.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/xinetd-2.3.14-46.fc17
xinetd-2.3.14-46.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/xinetd-2.3.14-46.fc16
Package xinetd-2.3.14-46.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xinetd-2.3.14-46.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-6047/xinetd-2.3.14-46.fc16 then log in and leave karma (feedback).
xinetd-2.3.14-46.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
xinetd-2.3.14-46.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.