Bug 748931 - xinetd needs network up and bind or other name resolution available
Summary: xinetd needs network up and bind or other name resolution available
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xinetd
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Jan Synacek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-25 15:35 UTC by Trever Adams
Modified: 2012-04-27 20:48 UTC (History)
1 user (show)

Fixed In Version: xinetd-2.3.14-46.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-27 20:48:57 UTC


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.