CentOS6 xinetd failure

One thing I have noticed on CentOS6 is that rsync via xinetd never
works after a reboot. It always takes an additional, post-reboot
service xinetd restart to get it going. That has been the same for
all revisions up to and including 6.5, and I've seen it on more than
just machine.

While I don't see such a message on other problem machines, the latest
reboot gave me a clue:

Dec 9 23:28:36 host xinetd[21131]: bind failed (Address already in use (errno = 98)). service = rsync
Dec 9 23:28:36 host xinetd[21131]: Service rsync failed to start and is deactivated.

Is there any way to debug this? I suspect it needs to be debugged
during reboot since the service starts up fine later.


Re: CentOS6 xinetd failure

By Helmut Drodofsky at 12/10/2013 - 10:03

<a href="" title=""></a>

I have had the same problem and I will never understand, why this is
unchanged up to now.

- erase nfs
- change sequence number in /etc/rc3.d

best regards

Viele Grüße
Helmut Drodofsky

Internet XS Service GmbH
Heßbrühlstraße 15
70565 Stuttgart

Dr.-Ing. Roswitha Hahn-Drodofsky
HRB 21091 Stuttgart
USt.ID: DE190582774
Tel. 0711 781941 0
Fax: 0711 781941 79
Mail: <a href=""></a>
<a href="" title=""></a>

Am 10.12.2013 11:37, schrieb Lars Hecking:

Re: CentOS6 xinetd failure

By Lars Hecking at 12/10/2013 - 11:22

Helmut Drodofsky writes:
Excellent, thanks! Now I know how to work around it. I've seen this happening
before, on CentOS5, when cups would sometimes not start.

Upstream knows this problem very well or they wouldn't have introduced
portreserve(1). Pretty hilarious they can't fix the actual problem.

Re: CentOS6 xinetd failure

By John Doe at 12/10/2013 - 09:37

"Address already in use" => check what is listening on port 873?
In the rsync xinetd conf it says IPv6 here...


Re: CentOS6 xinetd failure

By Lars Hecking at 12/10/2013 - 10:02

service rsync
disable = no
flags = IPv6
socket_type = stream
wait = no
user = root
server = /usr/bin/rsync
server_args = --daemon
log_on_failure += USERID

All machines are, correctly, showing that xinetd is listening on 873. But
this must not be the case for at least a period of time during system