Software Development and Consulting
Posts tagged ‘linux’
Every so often I see someone attempting to run the Linux kernel on a PCI add-in card. I’ve done this myself, but there are a lot of complications. This article covers the hardware, and a second article will cover software. Don’t take this as chipset selection advice: before you commit to hardware double-check both the errata and the availability of the silicon.
Continue reading ‘Running Linux on a PCI Add-in Card: Hardware’ »
I have now seen my first ever year 2038 bug. An embedded Linux system that was installed two years ago became unable to acquire a network address by DHCP. The machine did not require an accurate clock, and nobody had initialised its battery-backed real-time clock. Once installed, it had started counting forward from 1st January 1900.
32 bit Unix time covers a range from December 13th 1901 to January 19th 2038. As the real-time clock value was outside this range, Linux wrapped the time round to the year 2036. After the machine had been running for nearly two years, it passed through the 2038 rollover and jumped back to 1901.
This would have been harmless in itself if all the applications on the machine used a monotonic clock, such as the uptime counter returned from the sysinfo function. But the machine in question used an older version of Busybox, and the udhcpc DHCP client in that release failed when faced with a time in the negative number range before 1st January 1970.
The moral of the story? Even though a machine doesn’t need a real-time clock function, it may not be immune to clock related bugs.
After several years of use, the server for my development machines developed a problem. If I rebooted the machine without an internet connection, it would pause for several minutes while starting the NFS service.
The Linux NFS server keeps track of status in several files. Whenever a client mounts a filesystem, the server records this in /var/lib/nfs/rmtab. If the server reboots, exportfs passes this list to the kernel to ensure that the reboot is invisible to the clients. So far, this is harmless.
If the server is used with clients that do not send clean unmount requests, such as diskless machines in a development lab, then rmtab fills up with entries for machines that aren’t around anymore. This is mostly harmless.
The final part of the problem is that on reboot exportfs performs a reverse DNS lookup for each entry in rmtab. If the DNS server is unavailable, the request waits for a timeout. This can take a very long time.
And the moral of the story? If NFS clients come and go on your network, check rmtab for clutter.
