Using a virtual PTP hardware clock with the ptp_kvm
driver and chrony is an easy solution for keeping time on guest machines synchronized to their host. Ideally the host is already keeping accurate time by tracking a set of NTP servers, but it is still probably a good idea to still add some network NTP peers on guests as well. (more…)
18.9.22
Virtual PTP hardware clock on KVM guests
29.7.20
Clean up legacy network interface naming
Predictable network interface names are all the rage in Linux distros these days. My systems are of various vintage so most have carried on with eth0
and eth1
through upgrades by having old udev
rules kept around.
To get with the times a few steps are needed: (more…)
- »
- Today I wanted to use phpMyAdmin for the first time in quite a while, only to see errors when viewing a table. Lucky for me, there was an easy fix. (more…)
4.5.17
Network speed and IRQ affinity
By default many Linux network interface card drivers set their SMP affinity mask to either all zeroes or all ones (“ff” — the length of the mask depends on the number of CPUs on the system). The former results in all queues and interfaces running on CPU ID 0, which can become a performance bottleneck due to insufficient computing power. The latter results in all queues and interfaces being scheduled on multiple CPUs, which can become a performance bottleneck due to increased CPU memory cache misses. (more…)
16.10.16
Switch back to sysvinit
If you have already upgraded to jessie
and have systemd
as init
, you can switch back with these commands:
apt-get install -y sysvinit-core reboot apt-get purge -y systemd
Running with sysvinit
works better on my servers, as daemons have a chance of doing their own graceful shutdown before the network is brought down.
29.9.16
Stay with sysvinit
Before upgrading to jessie
, create /etc/apt/preferences.d/use-sysvinit
:
Package: systemd-sysv Pin: release o=Debian Pin-Priority: -1
See also: How to stay with sysvinit in Debian Jessie by Petter Reinholdtsen
21.2.14
Unbound not resolving
I’m not sure what failed last night, but I’m guessing the cable Internet connection was down. Interestingly, unbound had stopped resolving even local zones configured with stub-zone
and stub-addr
directives. This was unexpected: stub-zones are supposed to work “without referring to the public Internet” per the unbound.conf
manual page.
To mitigate the issue I wanted to have backup name servers in resolv.conf
(ones using a different Internet connection) even on the resolving name server hosts themselves. With resolvconf that boiled down to creating /etc/default/resolvconf
with the following setting in it:
TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS=no
This way name servers configured in /etc/network/interfaces
(using dns-nameservers
directives) are included in resolv.conf
even when unbound has been started.
However, this is a poor workaround, as I don’t have multiple Internet connections at every site.
13.5.13
Wheezy upgrades
Debian 7.0 “wheezy” was officially released about a week ago. I’ve been running it on a couple of systems for a few months already because of the more recent software versions available on it. Today I upgraded one of the shell servers, a couple of days ahead of the originally posted schedule due to security updates to MySQL (DSA-2667). As usual for Debian, the upgrade process is well documented1 and robust. However, here are some notes for upgrading the next instance. (more…)
6.6.10
Fixes to VMware Tools
I just patched a couple of ESXi hosts to 4.0.0 build 256968 and found that VMware Tools were no longer loading after upgrading them. After some digging everything is more or less back to normal. (more…)
2.6.09
Ubuntu doesn’t like AMD?
I’ve been observing a really strange problem on Ubuntu Server 8.04: processes are sitting in limbo not doing anything. I first observed this as phones losing their SIP registrations periodically (but at random intervals).
When debugging the issue, I saw that a ping
running on the system would often just sit there, not sending more packets, sometimes for seconds on end (I didn’t always wait to see if it would ever continue). Since hitting a key on the keyboard would immediately be echoed back, it wasn’t a problem with the terminal or ssh connection. Pinging the system from another would work without problems. Interrupting ping
would report no packet loss (which was true — you can’t lose replies to packets you didn’t send).
My best guess is that the alternative scheduler chosen by the Ubuntu developers for the server kernels doesn’t work as intended on AMD CPUs (or just the Athlon XP, or some other part of the hardware I’m using).
My “fix” was to switch to Debian 5.0 (lenny), which doesn’t exhibit this problem at all.
I could have tried with the desktop edition of Ubuntu, but can’t really spare the time right now. Especially since I now have something that works reliably again.
I did try with different network hardware, though. I was originally using an SMC card based on ns83820
(but for some reason not reporting anything at all with ethtool
— works fine with the gsip
driver on NetBSD). I then switched to a Netwjork “brand” card based on r8169
(well liked by ethtool
). No difference, but stayed with the latter (working ethtool
is always nice).