Bug 748931

Summary: xinetd needs network up and bind or other name resolution available
Product: [Fedora] Fedora Reporter: Trever Adams <trever>
Component: xinetdAssignee: Jan Synacek <jsynacek>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 16CC: vvitek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: xinetd-2.3.14-46.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-27 20:48:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Trever Adams 2011-10-25 15:35:00 UTC
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

Comment 1 Jan Synacek 2012-03-07 08:08:19 UTC
Could you please provide your setup so I can reproduce the issue?

Comment 2 Trever Adams 2012-03-07 20:39:04 UTC
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.

Comment 3 Jan Synacek 2012-03-08 09:41:41 UTC
> 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' ?

Comment 4 Trever Adams 2012-03-08 22:01:32 UTC
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.

Comment 5 Jan Synacek 2012-03-09 08:06:50 UTC
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.

Comment 6 Jan Synacek 2012-04-16 06:35:18 UTC
Fixed in rawhide:
http://lists.fedoraproject.org/pipermail/scm-commits/2012-April/770014.html

Comment 7 Fedora Update System 2012-04-16 11:07:45 UTC
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

Comment 8 Fedora Update System 2012-04-16 11:24:27 UTC
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

Comment 9 Fedora Update System 2012-04-18 19:34:44 UTC
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).

Comment 10 Fedora Update System 2012-04-22 04:21:47 UTC
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.

Comment 11 Fedora Update System 2012-04-27 20:48:57 UTC
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.