## Power failure tonight, downtime.

This evening, Montreal experienced a forecast, severe thunderstorm. But what could not be forecast with certainty, was whether the power would fail, in my exact neighborhood. In fact, it did.

I take the somewhat unusual approach, of hosting my Web-site, and therefore also this blog, on my PC at home. The availability of this blog can therefore not be any better, than the availability of my PC, to the Internet. Therefore, this site and blog were briefly offline, from about 19h00 until 20h00. I apologize for any inconvenience to my readers.

Dirk

## Planned Power Cut Today

One of the subjects I wrote about in past months, was that My power utility had been planning to cut power to my home, briefly, to perform work on the -distribution system. This had to do with our wireless power meters, that needed to be replaced.

Because the linemen knocked on my door, and forewarned me of the power cut, in order to avoid any file-system corruption, I actually shut down all my computers, one of which acts as my Web-server.

As a result of my shutting the computers down, my site and blog were off-line from about 13h30 until 14h20 this afternoon. I apologize for any inconvenience to my readers.

The actual power-cut only lasted approximately 5 minutes, but because I did not know the exact timing with which it would take place, I was cautious and shut down my computers at 13h30 already.

This time around, the X-server on the computer named ‘Phoenix’ took 2 attempts to restart.

At least this power-cut resolved an outstanding issue.

Dirk

## Kernel Update today, Downtime, Multiple Reboot-Attempts

Today, the PC which is hosting my site and blog, which I name ‘Phoenix’, received a kernel update.

Debian Team has not been following standard guidelines in their propagation of kernel updates, as the last 3 updates produced the same kernel-version number:


3.16.0-6-amd64



Because even Linux computers require a reboot after a kernel-update, this blog was temporarily off-line from about 13h05 until 13h25. I apologize for any inconvenience to my readers.

There is a fact about the build of Linux on this computer which I should bring up. I have the following on-board graphics-chip:


GeForce 6150SE nForce 430/integrated/SSE2



And this proprietary graphics driver is the only one, capable of working with the said graphics-chip:


NVIDIA 304.137



The graphics driver is installed from standard Debian repositories.

Somewhere between these software-packages there is a problem, which Debian Team has never been aware of, but which has existed ever since I installed Debian / Jessie on this computer. Directly after a reboot, the ability of the X-server to start, is not reliable. Sometimes, the X-server starts on the first try, but on other occasions I need to make 7 reboot attempts, before the X-server will start, and from one reboot-attempt to the next, I change nothing.

Once the X-server has started successfully, this graphics-chip will work 100% for 30 days !

I have been reluctant to point this out for the past few years, because if a Debian developer finds out about it, he will try to fix this problem. And when he does, he will brick my computer.

This afternoon, 7 reboots were in fact required, before the X-server started. That is why the reboot-procedure took 20 minutes of time.

(Updated 07/14/2018, 16h45 … )

## A Problem which can befall Dropbox under Linux (Unable to Access -Folder).

This is a problem which has happened to some of the Dropbox customers, who have the client installed under Linux:

The Dropbox Icon changes to a grayed-out icon, with a red cross, and when we click or right-click on the icon, it says it’s unable to access (its) Dropbox folder. It even asks us for our Linux Password (apparently Windows-gurus don’t understand Linux), in a bid to correct the permissions of the folder in question. Don’t enter any password. At the same time, if we have a very complex desktop-management system running, we may find that the Desktop and its management-software become laggy to almost non-functional, especially with ‘Baloo’ running etc..

In my case this was due to the combination of two factors:

1. I had added many, systematically-named files to my Dropbox folder from another synced computer, due to backing up newly-installed software.
2. Dropbox uses a feature called ‘INotify’, so that a program gets notified as soon as the contents of a file are changed, which that program has placed a watch on. In this case, Dropbox has a watch on thousands of files.

In my case, the following helped. On a Debian-based system, in a terminal-window, type:


dirk@Phoenix:~\$ su
root@Phoenix:/home/dirk# cd /etc
root@Phoenix:/etc# edit text/*:sysctl.conf



Then, edit the file in question, to contain the following two lines:


fs.inotify.max_user_watches = 262144
fs.inotify.max_user_instances = 256



Then, to make the changes take effect, type:


root@Phoenix:/etc# sysctl -p



What this does is set the kernel limits ‘very high’, as to how many INotify-watches it will support. For the moment, the Dropbox client on this machine is stable again.

(Updated 07/03/2018, 8h35 … )

(As of 07/02/2018, 11h25 : )

Actually, according to my own recent experience, after applying the above fix, if the limit already did run out, a reboot is nevertheless required.

And because of the needed reboot, my server was also down for about 10 minutes this morning…