Take the 2-minute tour ×

Silly question... I can't get xinetd to start on my linux box (CENTOS 4.8).

I've got so far as to remove it and reinstall it via yum. When I try to start it, stop it, etc. I get no error at all.

   [root@server ~]# service xinetd stop
   [root@server ~]# service xinetd start
   [root@server ~]# service xinetd restart

I would expect to see some standard status from the system (e.g. "Service Started - [OK]" I also don't see any log entries in /var/log/messages

I've tried running the init script with the -d option but nada. No errors. No confirmation messages that the service started. Nothing.

Any ideas?

[UPDATE] - As per recommendations, here's an output of cat /etc/init.d/xinetd

# xinetd        This starts and stops xinetd.
# chkconfig: 345 56 50
# description: xinetd is a powerful replacement for inetd. \
#              xinetd has access control mechanisms, extensive \
#              logging capabilities, the ability to make services \
#              available based on time, and can place \
#              limits on the number of servers that can be started, \
#              among other things.
# processname: /usr/sbin/xinetd
# config: /etc/sysconfig/network
# config: /etc/xinetd.conf
# pidfile: /var/run/xinetd.pid


# Source function library.
. /etc/init.d/functions

# Get config.
test -f /etc/sysconfig/network && . /etc/sysconfig/network

# More config

test -f /etc/sysconfig/xinetd && . /etc/sysconfig/xinetd

# Check that we are root ... so non-root users stop here
[ `id -u` = 0 ] || exit 1

# Check that networking is up.
[ "${NETWORKING}" = "yes" ] || exit 0

[ -f /usr/sbin/xinetd ] || exit 1
[ -f /etc/xinetd.conf ] || exit 1



    echo -n $"Starting $prog: "

# Localization for xinetd is controlled in /etc/synconfig/xinetd
    if [ -z "$XINETD_LANG" -o "$XINETD_LANG" = "none" -o "$XINETD_LANG" = "NONE" ]; then
    daemon $prog -stayalive -pidfile /var/run/xinetd.pid "$EXTRAOPTIONS"
    touch /var/lock/subsys/xinetd
    return $RETVAL

    echo -n $"Stopping $prog: "
    killproc $prog
    rm -f /var/lock/subsys/xinetd
    return $RETVAL


    echo -n $"Reloading configuration: "
    killproc $prog -HUP
    return $RETVAL


    [ -e /var/lock/subsys/xinetd ] && restart
    return 0

# See how we were called.
case "$1" in
        status $prog
        echo $"Usage: $0 {start|stop|status|restart|condrestart|reload}"

exit $RETVAL
share|improve this question
Are there any services enabled, so that xinetd has a reason to start? –  Zoredache Oct 25 '09 at 0:29
Hi Zoredache, how do I check that? I'm trying to get tftp-server working and it requires Xinetd. –  Mike B Oct 25 '09 at 1:54
add comment

9 Answers

up vote 1 down vote accepted

Use "strace" command to debug xinetd, example:

yum install strace
strace /usr/sbin/xinetd 2>&1 | tee log.txt

Then examine log.txt to see what's going wrong with your configuration.

I would recommend you to backup your configurations, uninstall xinedt, remove /etc/xinetd.conf and /etc/xinetd.d/ and then install it again using yum. When you'll be able to start it you can add more services step by step.

share|improve this answer
Interesting. So it xinetd (and the services) works perfectly fine if I just type /usr/sbin/xinetd. I'm not quite sure what that means but at least it's progress. Thank you. –  Mike B Oct 27 '09 at 4:47
add comment

When a service doesn't start and doesn't give an error message, it's probably worth trying to start the service by hand. The first thing to do is to run:

# bash -x /etc/init.d/xinetd start

This will show you all the commands that are being run to start the service. This might give you a clue as to why it isn't starting. If it doesn't then you can find the final command used to start the daemon and run that by hand. This usually proves helpful. If this still doesn't help, you should run the command under strace.

(Note: I've not used CentOS in a long time, so paths and things might not be correct. I don't think it uses upstart yet, but if it does, look in /etc/event.d/xinetd or /etc/init/xinetd.conf and that should have the command to run by hand.)

share|improve this answer
add comment

You might get some helpful information if you bypass the startup script altogether and run xinetd directly with the debug flag -d.

/usr/sbin/xinetd -f /etc/xinetd.conf -d

On my Gentoo box when I don't have any services defined the above command will exit after the below the debugging output

09/10/26@21:26:05: DEBUG: 23117 {cnf_start_services} mask_max = 0, services_started = 0
09/10/26@21:26:05: CRITICAL: 23117 {init_services} no services. Exiting...

With a service enabled (chargen in this case, in /etc/xinetd.d/chargen-stream change the line 'disable = yes' to 'disable = no') running the above command produces the following output and the xinetd does not exit until hit Ctrl-c.

09/10/26@21:41:00: DEBUG: 23261 {cnf_start_services} Started service: chargen-stream
09/10/26@21:41:00: DEBUG: 23261 {cnf_start_services} mask_max = 6, services_started = 1
09/10/26@21:41:00: NOTICE: 23261 {main} xinetd Version 2.3.14 started with libwrap loadavg options compiled in.
09/10/26@21:41:00: NOTICE: 23261 {main} Started working: 1 available service
09/10/26@21:41:00: DEBUG: 23261 {main_loop} active_services = 1

As a side note, if you run the init script with chargen enabled then you should be able to use netstat to see xinetd listening on the chargen port by running the following command:

netstat -tap | grep xinetd

The output should look something like this:

tcp    0   0 *:chargen        *:*       LISTEN     23439/xinetd
share|improve this answer
add comment

To me usually that is an indication that there is something wrong with the script to control the service, ie the variable that has the binary isn't pointing to the right location.

Can you cat /etc/init.d/xinetd and let us see what it says?

share|improve this answer
Added the output of the script to the main question summary above... sorry -- I'm still not quite up to speed with Linux. Does anything stand out? –  Mike B Oct 25 '09 at 1:48
What you could do is add echo statements after some lines to see where in the script it gets up to. In Linux scripting, it goes from top to bottom. So, I would put some echo statements before some of the test statements like echo "Testing for sysconfig/network" And also put echo statements before the tests inside of the [ ] brackets like echo "Checking for root" This way you can see where the script is failing and exactly why. I am not a CentOS guru, but this is defiantly a good place to start in my opinion. Want me to post the script edited with comments (echo statements)? –  Nathan Adams Oct 25 '09 at 2:06
That would be great if you could. I've never edited an init script before. –  Mike B Oct 25 '09 at 2:08
This should work: pastebin.com/m700ca094 ; I would run: "cp /etc/init.d/xinetd ~" So that it copies an original version to your home directory. Then just transfer the version I wrote up to your server using vi, cp, cat, nano ect. –  Nathan Adams Oct 25 '09 at 3:44
add comment

xinetd is a strange beast. As Zoredache mentioned, it won't start unless it has something to do. You state your trying to get tftpd running, which runs through xinetd.

By default, when tftpd-server is installed, it places a file called tftp in /etc/xinetd.d. A directory xinetd looks in when it starts to see if it has anything to do. In the /etc/xinetd.d/tftp file, see of there is a line that says "disable = yes". If there is one, that is probably your problem. xinetd starts, reads the file but is being told tftp is disabled. So with nothing to do it exits.

To solve this problem (if this is indeed the problem), edit the /etc/xinetd.d/tftp file and change the "disable = yes" to "disable = no". Now try restarting xinetd.

share|improve this answer
Hi David. Thanks for the prompt feedback but xinetd still doesn't start unfortunately. –  Mike B Oct 25 '09 at 3:02
xinetd logs to /var/log/messages when it starts. See if there are any error messages there. For example, on my CentOS 4.7 box, I see: Oct 24 23:04:55 slack xinetd: xinetd startup succeeded Oct 24 23:04:55 slack xinetd[12517]: xinetd Version 2.3.13 started with libwrap loadavg options compiled in. Oct 24 23:04:55 slack xinetd[12517]: Started working: 4 available services –  David Oct 25 '09 at 3:06
If you change the first line of /etc/init.d/xinetd to "#!/bin/bash -x" it will print out all the commands the script runs. Think of it as a verbose mode. Maybe one of the commands is failing. –  David Oct 25 '09 at 3:10
add comment

Couple things to check:

Your /etc/xinetd.conf should look something like this:

    instances               = 60
    log_type                = SYSLOG authpriv
    log_on_success          = HOST PID
    log_on_failure          = HOST
    cps                     = 25 30
includedir /etc/xinetd.d

You should also check the permissions of the xinetd script and any related binaries and files, make sure they are executable if need be, etc. Sounds trivial but these things are sometimes overlooked (much to an admin's dismay after hours of wrangling.)

Since the 'disable = yes' bit was already covered, that's not the issue.

You can edit /etc/sysconfig/xinetd to pass these arguments to xinetd:

-d -dontfork -- this will enable the debug mode and cause xinetd to stay "alive" even though nothing is running, perhaps it'll give you more insight.

share|improve this answer
add comment

Had similar problem on CentOS x64 running on OpenVZ with veth.

Commented out this line: [ "${NETWORKING}" = "yes" ] || exit 0

Just place # before this line in /etc/init.d/xinetd and it works for me now. I think it's a problem with networking check when using veth interface.

share|improve this answer
add comment

If it's not working with the service command, make sure xinetd is actually registered as a service using chkconfig (it looks from your script as if it is registered, but still ...):

chkconfig --list xinetd

You should see:


If all levels are off, or if xinetd is not registered as a service:

chkconfig --add xinetd
chkconfig --level 345 xinetd on
share|improve this answer
add comment

In RHEL the NETWORK variable is evaluated in /etc/sysconfig/network which is sourced vi the init script. Your variable is probably set to NETWORKING=no or not set at all. If you set this value you should be all set

share|improve this answer
add comment

Your Answer


