User avatar
TerryC65
Posts: 151
Joined: Sat May 09, 2015 7:50 am
Location: Wimborne, Dorset, UK

Cannot get xinetd to serve time for rdate

Tue May 14, 2019 11:02 am

Hi,

Back in Sept 2017, I installed a RASClock on the 'master' Pi at our local model town and utilised rdate on all the remote Pis to synchronise the clocks to the master Pi. At the time, I had one or two problems, the worst being that I hadn't realised that the master Pi needed a time server to respond when the remote Pis queried the time with rdate. Once I discovered that xinetd would do the job, the system has been working ever since.

Recently, we've expanded the system with one more remote Pi and a major upgrade to the hardware for another. As it had been so long, I decided to upgrade Raspbian on all the Pis and at the same time use the Lite version instead of the full one now that most of the development work has been completed.

I have an Installation Specification that has been developed as we went along, but due to an oversight, I neglected to detail the installation of xinetd on the master Pi's SD Card, so it wasn't done when I built the new card. I am currently attempting to install it retrospectively. Since the system on site is working 24/7, I didn't want to have to shut down the master Pi to do it. The system does not have Internet access, so I used the info at http://www.penguintutor.com/raspberrypi/apt-get-offline to identify the needed packages and installed them onto a duplicate Pi here in my workroom. I then implemented a second Pi to behave as a remote and installed rdate on it.

Having booted both Pis, I tried to send:

Code: Select all

rdate -v 192.168.0.2
from the remote (where that IP is the pretend master). I got the same error as I got way back in 2017 before I discovered xinetd:

Code: Select all

rdate: Could not connect to socket: Connection refused
I've done a fair bit of investigation and cannot see what has gone wrong. The default xinetd.conf file and its included files in the directory xinetd.d (including time) seem OK, so I had a look at syslog. Here are the relevant lines:

Code: Select all

May 14 11:08:53 sumppi systemd[1]: Starting LSB: Starts or stops the xinetd daemon....
May 14 11:08:53 sumppi xinetd[501]: Starting internet superserver: xinetd.
May 14 11:08:54 sumppi systemd[1]: Started LSB: Starts or stops the xinetd daemon..
May 14 11:08:54 sumppi xinetd[511]: Reading included configuration file: /etc/xinetd.d/chargen [file=/etc/xinetd.conf] [line=14]
May 14 11:08:54 sumppi xinetd[511]: Reading included configuration file: /etc/xinetd.d/daytime [file=/etc/xinetd.d/daytime] [line=28]
May 14 11:08:54 sumppi xinetd[511]: Reading included configuration file: /etc/xinetd.d/discard [file=/etc/xinetd.d/discard] [line=26]
May 14 11:08:54 sumppi xinetd[511]: Reading included configuration file: /etc/xinetd.d/echo [file=/etc/xinetd.d/echo] [line=25]
May 14 11:08:54 sumppi xinetd[511]: Reading included configuration file: /etc/xinetd.d/time [file=/etc/xinetd.d/time] [line=26]
May 14 11:08:54 sumppi xinetd[511]: removing chargen
May 14 11:08:54 sumppi xinetd[511]: removing chargen
May 14 11:08:54 sumppi xinetd[511]: removing daytime
May 14 11:08:54 sumppi xinetd[511]: removing daytime
May 14 11:08:54 sumppi xinetd[511]: removing discard
May 14 11:08:54 sumppi xinetd[511]: removing discard
May 14 11:08:54 sumppi xinetd[511]: removing echo
May 14 11:08:54 sumppi xinetd[511]: removing echo
May 14 11:08:54 sumppi xinetd[511]: removing time
May 14 11:08:54 sumppi xinetd[511]: removing time
May 14 11:08:54 sumppi xinetd[511]: xinetd Version 2.3.15 started with libwrap loadavg options compiled in.
May 14 11:08:54 sumppi xinetd[511]: Started working: 0 available services
Is xinetd meant to remove the services immediately after loading them? That seems a bit odd.

Is there something different with the latest versions of Raspbian or Lite? Or is it because I've tried to install the packages offline?

User avatar
TerryC65
Posts: 151
Joined: Sat May 09, 2015 7:50 am
Location: Wimborne, Dorset, UK

Re: Cannot get xinetd to serve time for rdate

Tue May 14, 2019 12:05 pm

I've fixed it. :)

It was a dumb mistake; the default config files in xinetd.d all have the services disabled. I just had to change 'disabled=yes' to 'no'.

I don't remember doing that in 2017, (but then I didn't remember having to install xinetd in the first place). :oops:

Hopefully, this posting won't go entirely to waste as it might help someone else who may be doing something similar.

Return to “Troubleshooting”