3

We're currently working on a new server, for an avionics system.

This server normally uses Debian Stretch. But the hardware we use has no battery to save the clock. After reboot, the factory date/time is restored. The server will probably not be connected to any NTP server over the internet.

I was wondering if it could cause some dysfunctions with services or kernel apps?

Furthermore, a version of this server might use the ASTERISK framework to provide onflight telephony services. Again, I was wondering if this could become a blocking issue ?

I'm not competent enough in the matter to figure out a potential impact.

Improve this question
4
  • 1) Some server PCs have a supercapacitor to keep the real time clock going instead of a battery. Do you mean to say there is nothing to keep the real time clock of the server going? 2) Will there be an NTP server elsewhere in the avionics of the destination aircraft? Commented Apr 28, 2020 at 18:08
  • Debian 9 uses systemd 232, and "factory date/time" is not quite the right description for what systemd has done since version 229. Commented Apr 28, 2020 at 18:19
  • I am guessing that the server will have no internet connection at all. Am I right? Besides, is a writeable filesystem available on the server? If so, is it ext3 or xfs or something else? Commented Apr 30, 2020 at 22:48
  • @AndersonMedeirosGomes Yes. No internet connection. The filesystem remains writable. And it's an ext3 filesystem. Commented May 11, 2020 at 13:43

2 Answers 2

Reset to default
1

Debian Linux is not dependent on time accuracy for its own servers, kernel, and apps, but I would manually enter a time after booting if no time source server is available.

However, communications with other servers may well require it, but you've only mentioned asterisk. The asterisk server can also be running an ntp service to meet the connectivity requirements of telephony services it connects to.

Improve this answer
2
  • I'd be thinking about superblock timestamps, systemd journal timestamps, and multilog/cyclog filenames and line timestamps at this point; even disregarding encryption and billing in any telephony. Commented Apr 28, 2020 at 18:55
  • Those will be internally consistent. Commented May 5, 2020 at 15:10
0

I believe that an inaccurate clock will not be an issue for the kernel and applications running on server. However, some applications and services may present issues if they detect a clock shifted backwards. For example:

  • EXT2/3/4 filesystems trigger forced file system checks if they detect that either the last mount time or last write time is beyond the current time (workaround here).
  • Logrotate will not be able to rotate and purge old log files from /var/log.
  • Applications relying on locally-generated x509 certificates for mutual authentication may stop working due to validity start dates set to the future.

Your server has a writeable file system. So a viable approach for the system is to prevent the clock from going backwards by storing the clock on it. The fake-hwclock package comes handy for such demand:

# apt-get update
# apt-get -y install fake-hwclock
# fake-hwclock save
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.