Recent Update to libevent

Sometimes updates come through the package manager, which I do not blog about immediately. One such update took place in recent days, to the package ‘libevent-2.0-5‘.

After the update, I assumed that most of the programs which depended on this library were user-space applications. So I logged out my session and logged back in, without affecting system services such as the Web-server or ‘memcached‘. This maintenance-action of mine went by uneventfully – no pun intended. And doing so also restarted my X-server.

But then I decided to inquire, which services exactly depended on this library. And it turns out that ‘memcached‘ was the single process which remained, that did, and which therefore also deserved a restart. So I restarted this daemon tonight, thus flushing the cache. Therefore, response to readers of this blog might seem a little slow in the next few days.

Aside from that, I have a quiet feeling that by updating this library, the Debian Team may have fixed my spring.



NoMachine NX

When people connect to their VPN, this could simply allow them to access shared files. But alternatively, this could also mean that they wish to create a virtual session, on the remote desktop of one of their servers. The latter exists under the terms VNC, RDP, XRDP, and several others.

On my main Linux server named ‘Phoenix’, I have the XRDP service installed, which is the Linux equivalent of RDP. But one main drawback of this method, of remotely accessing a desktop, is the fact that XRDP does not allow file-sharing, specifically in the version of this protocol that runs out-of-the-box from the package manager. I have read that certain custom-compiled versions support this, but do recall that this service is a mess to custom-compile, and to set up in such a way that it runs reliably. So I stick to the packaged version for now, and do not obtain file-sharing.

There exists a closed-source application named NoMachine NX, which we could use to bridge this gap. But while their paid software subscriptions are very expensive (from my perspective), their Free software version has some big disadvantages.

First of all, even their Free version can be run in client or in server mode. I think that this is terrific. But in server mode – which affords access to the local machine desktop from elsewhere – there is no built-in support for SSH protocol. There is only the unencrypted NX protocol, for which their service listens.

Secondly, not every computer is strong enough to run NoMachine NX in server mode. On the computer ‘Phoenix’ I have a fragile X-server, and this service has actually crashed my X-server. Not only that, but allowing this service to run on reboot, consistently prevents my X-server from starting. It gets its hooks into the session so early on boot, that the X-server crashes, before the user is even asked for a graphical log-in.

On the plus side, there are ways of solving both problems.

Continue reading NoMachine NX

Another possible hypothesis, for why my server-box sometimes crashes.

I have written before, that my Linux computer ‘Phoenix’, which acts both as my server and a workstation, sometimes crashes. I have another possible explanation for why.

The graphics chip on this machine is only a GeForce 6150SE nForce 430/Integrated/SSE2, capable of OpenGL 2.1.2 using proprietary (legacy) drivers. It only has 128MB of shared memory with my motherboard.

Under Windows 10, this chipset is no longer supported at all.

I may simply be pushing this old GPU too hard.

My display is a 1600×1200 monitor, and much of the graphics memory is simply being taken up by that fact. Also, I have many forms of desktop compositing switched on. And at the time of the last crash, I had numerous applications open at the same time, which use hardware 2D acceleration as part of their canvas. And I was copying and pasting between them.

I am hoping that this is easing the burden on my equally-dated CPU.

But then the triggering factor may simply be an eventual error in the GPU.

The fact that the Timeout Detection and Recovery (‘TDR’) does not kick in to save the session, may be due to the possibility that the TDR only works, in specific situations, such as OpenGL, 3D rendering windows. If the GPU crash happens as part of the compositing, it may take out the X-server, and therefore my whole system.

The only workaround I may have, is to avoid using this box as a workstation. When I avoid doing that, it has been known to run for 60 days straight, without crashing…


(Edit 01/28/2017 : )

I use a widget on my desktops, which is named ‘gkrellm’, and I find that it gives me a good intuitive grasp of what is happening on my Linux computers.




This widget has as a disadvantage, that when extensions have been installed to display temperatures, sometimes we do not know which temperature-sensors stand for which temperature. This is due to the fact that Linux developers have to design their software, without any knowledge of the specific hardware it is going to run on. Inversely, the makers of proprietary drivers know exactly which machine those are going to run on, and can therefore identify what each of them stands for.

This also means, sometimes we have temperature readings in ‘gkrellm’, which may just be spurious, and which may just constantly display one meaningless number, in which case we reduce our selection of indicated temperatures to ones we can identify.

In the context of answering my own question, another detail which becomes relevant, is the fact that this tower computer has a failed case-fan, which is accurately being indicated as the ‘FAN1 – 46′ entry, running at 46 RPM at the moment of the screen-shot. I know that this case-fan is in fact stalled, from past occasions when I opened up the tower.

Continue reading Another possible hypothesis, for why my server-box sometimes crashes.