libc Updates today, Downtime

This computer is a Debian / Jessie (Linux) system. Just today, it mainly received an update to its ‘libc‘ libraries, that comprised 16 packages. These libraries are essential to the core of how every program works. Therefore, even though it is a Linux system, it needed a reboot.

The update seems to have gone smoothly, but because this computer is also my Web-server, my site and blog would have been offline from about 20h30 until 20h45.

It is also not feasible for me to display a Maintenance Mode page during such a time, because a Web-server would need to be running, in order actually to display a Maintenance Mode page.

I apologize for any inconvenience this 15-minute interval may have caused to my readers, but it was essential.

Also, because this was a full reboot of my host-machine, my ‘memcached‘ (server-side) caching daemon was restarted, for which reason the most-favorite postings retrieved by my readers will be a bit slow to fetch for some time.

Sorry again,



Major Upgrade This Evening, Downtime

Both the Linux-laptop I name ‘Klystron’, and the server of this Web-site, this server being named ‘Phoenix’, received a major update this evening. On ‘Phoenix’, a total of 78 packages needed to be updated, including a Kernel-Update, and a Graphics-Driver Update. This collective update effectively converted both computers from Debian 8.7 to Debian 8.8 systems. And both updates appear to have succeeded, at first glance without breaking anything.

However, this was an update that required a reboot for ‘Phoenix’, even though this is my Web-server, and so my site was also down briefly, from approximately 20h40 until 20h50.

I am happy to say however, that ‘Phoenix’ had been running for 58 days straight, without requiring any reboot whatsoever until tonight.

Oh, but I must disappoint some of my readers with the fact that performing these updates also required I restart my ‘memcached‘ service, which means that pages or postings the readers like to visit most often will be a bit slower to fetch, until this server-side caching is replenished.



Routine Kernel-Update Today, Downtime

I take the unusual measure, of hosting my Web-site on my own server. Yet, from time to time, updates come to this same host-machine – which I name ‘Phoenix’ – and some of those updates require a reboot, even though it is a Linux computer. When I do this, my site temporarily becomes unavailable. In fact, even though my installation of ‘WordPress’ has a page, I am unable to display it in most cases, because that page still requires for a Web-server to be running, to display on your browser.

Just today, there was a Kernel Update pushed through the package manager, to Kernel version . And so I felt it was only reasonable to perform the reboot. Also, there were some more-minor updates to ‘‘, but those would not usually, by themselves, require a reboot.

Because the entire process ran smoothly and without notable incident, my site and blog were only offline from about 12h35 until 12h45.

I apologize for any inconvenience.

Also, because my ‘‘ daemon has been restarted, this blog will seem a bit sluggish for the next day or so.



New Case-Fan Installed

During previous postings, I had written about crashes, which the computer I name ‘Phoenix’ was suffering from. And I had written that one possible reason could have been the failed case-fan, which could have been causing something on the motherboard to overheat.

Just today, this box suffered from another similar crash. This time, I opened up the case, and replaced the 92mm case-fan. Therefore, the reader might expect some optimism on my part, that this server-box will not crash again. But in reality I have two reasons, for which my optimism does not overwhelm:

  1. If an overheated chip has already caused crashes, there is some tendency for it to suffer from a memory-effect, of wanting to fail again, whenever it gets slightly warm, or just so. Therefore, due to the first crash possibly having happened for that reason, this machine could now have a penchant for crashing, even though the initial cause has been removed.
  2. The cause may not have been an overheated chip, but rather, a pure software-problem with the legacy graphics driver (nVidia). On such a big display, the graphics driver may have been suffering from some sort of resource leak – aka memory leak – and during boot-up, the BIOS displays it only possesses 128MB of shared RAM! Thus, the problem could be cumulative and result from regular copying-and-pasting, with many HW-accelerated drawing surfaces and many compositing effects enabled. Once we have an unstable graphics driver – and the graphics driver has received several updates recently – having a stable one could be a luxury we cannot easily reproduce.

I was down from roughly 19h00 until 20h00, and apologize to my readers for any inconvenience.


BTW: I have an additional reason, not really to believe, that these crashes are due to an overheated graphics chip. During the actual reboot, the graphics chip should get especially hot, and especially so, if the case-fan is not turning.

I can see that if this chip did overheat, the TDR would not be able to reboot it.

But the crashes never seem to occur, directly after the reboot. I generally seem to obtain about 6 days of smooth computing, before another crash happens.

Also, it should not be a VRAM leak, because this is a pre-GPU-type graphics chip. With the old graphics chips, that maximally had several pixel and several vertex pipelines, VRAM consumption was more or less static, while with the more-modern GPUs, some amount of VRAM-creep is at least plausible.


root@Phoenix:/home/dirk# lspci | grep vga
root@Phoenix:/home/dirk# lspci | grep VGA
00:0d.0 VGA compatible controller: NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2)
root@Phoenix:/home/dirk# lspci -v -s 00:0d.0
00:0d.0 VGA compatible controller: NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) (prog-if 00 [VGA controller])
        Subsystem: Hewlett-Packard Company Device 2a61
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 21
        Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
        Memory at e0000000 (64-bit, prefetchable) [size=256M]
        Memory at fc000000 (64-bit, non-prefetchable) [size=16M]
        [virtual] Expansion ROM at f4000000 [disabled] [size=128K]
        Capabilities: [48] Power Management version 2
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
        Kernel driver in use: nvidia