Kernel Update, Downtime

I take the unusual approach, of hosting my blog on my own Web-server at home. Tonight, this host machine, named ‘Phoenix’, received a standard Debian Kernel Update via the package manager.

This procedure is routine, but requires a reboot, even from a Linux computer.

The visibility of my site and of my blog, was affected from approximately 21h40 until 21h55. Also, because the server itself was rebooting, it was not possible to have it display a Maintenance Mode image.

I apologize for any inconvenience.

Further, the Server response may be a bit sluggish for the next few hours or day, simply because its cache gets cleared, when we reboot.

The last session, that I just rebooted, had been running for 31 days continuously.



Reboot, Downtime

I host my Web-site on my private computer at home, the one I name ‘Phoenix’. This is different from how most Web-sites today are hosted.

Phoenix received a kernel-update today by way of the package manager, which also required a routine reboot. As a result, my Web-site would have been inaccessible from about 20h05 to 20h15.

Also, I could not have posted a notification on my actual blog, indicating Maintenance Mode, because to output such a message would at least require that the server itself be running. Yet, there has been no real disruption to my Web-server, outlasting this reboot.

I apologize for any inconvenience.



Klystron Kernel Update Ends Suspend To RAM Experiments.

Only a few days ago, because that laptop is fully subscribed to Kanotix, the computer with the network name ‘Klystron’ received another kernel update, this time to version ‘4.4.0-34-generic‘, which for some reason also goes by the name ‘4.4.0-35Kanotix‘. This has had slightly sad, but also good consequences:

  1. I can no longer allow Klystron to Suspend To RAM, as by now, doing so sets the time-last-modified of the super-block of its FS into the future. In fact, after a recent reboot, the log-in manager also reported to me, that it was unable to enter the home directory of the main user. This gave me quite a shock, until I noticed, that I was still able to log in as the auxiliary user, after which a full reboot also fixed the super-block. What this means is that all my experiments with Suspend To RAM must end, including hoping that its WiFi chip-set will work after resuming. But, I had written several times, that the performance of the WiFi had improved, as long as I do not suspend the laptop…
  2. I can now focus on a user-configuration, by which closing the laptop lid locks it, but hopefully, the WiFi will stay connected. In hopes of improving the chances of that, in addition to the fact that support may have already been improved in the latest kernel versions, I have additionally set my router only to use a signal-width of 20MHz, i.e. not to use ‘channel bonding’. My logic behind that is, that higher speeds might look good, as long as the signal strength is good. But to cope with the possibly weaker signal of the lid being closed, a narrower WiFi signal-width, as set from the router, may help improve reliability.

But whether that pans out, only time will be able to tell. Even if it does not, simply having the WiFi disconnect and then reconnect, as I reopen the lid, should not be the end of the world.



Latest Kernel Update Fails To Solve One Specific Problem.

According to my recent postings, the Linux laptop I name ‘Klystron’ has received a kernel update to version 4.4.0-30-generic. In This Posting, I had written of a specific bug that happened on the laptop, whenever I told it to Suspend To RAM. Specifically, after Resuming, the system clock would end up set exactly 68 hours into the future.

According to my latest test, This latest kernel update did not solve that problem. Therefore, for the time being, I will need to rely on a script which I specifically adapted, to correct the error whenever it happens.