I came across a couple of really good blog entries published by Chris Siebenmann recently (incidentally, this is a highly recommended blog). The first one provides an example on the temptation to write shell scripts to accomplish something when a different programming language should be used instead. I must say, nevertheless, that, since pretty much everything I write is for personal use, I haven't truly come across the problems he describes. As a matter of fact, if anything, taking part in a more official development team at SGI to put together a monitoring tool in bash shell taught me that shell scripting is far more capable than people give it credit for. Better yet, I learned that plenty of projects written in other languages could actually be written in shell just fine. In any case, Siebenmann does make some good points. The second article is, perhaps, more useful. In Some things that make shell scripts have performance issues, Siebenmann discusses what is it that causes shell scripts to perform poorly. It all boils down to an important consideration: the cost of starting separate programs. {link to this entry}

Due to some strange screen lock-ups, I recently decided to switch my Debian 10 (buster) laptop from the free nouveau drivers to the proprietary Nvidia drivers. It's more of a manual process, but it is well documented. Also, I had to make some adjustments to the default settings here and there. But all that is normal, and to be expected. Altogether, I may have spent about an hour or two playing with things. But, in the end, it worked. However, the following day, when I finally sat down to work, and used the laptop for a full day's work, I noticed the fan was constantly spinning. Also, CPU and disk utilization was higher than usual. Since I had to work, I couldn't pay much attention to it, though. One way or another, by the end of my workday, I tried to launch an app, and it failed due to lack of free space on the root partition (?!). It took about one more hour of work to figure out what had happened: for whatever reason, the file /var/log/auth.log had grown to be over 4GB in size. Worse yet, running tail -f on it clearly showed that new messages were being printed on it at an alarming rate. The messages looked like these:

Jan 29 15:40:14 server systemd-logind[438]: Suspending...
Jan 29 15:40:14 server systemd-logind[438]: Failed to execute operation: Unit suspend.target is masked.

In other words, systemd-logind was storming the logs with constant, non-stop messages. The solution is documented in this StackExchange thread:

1. As root, edit the file /etc/systemd/logind.conf.
2. Add HandleLidSwitch=ignore to the file.
3. Restart logind with the command systemctl restart systemd-logind.

So, what's going on here is that systemd-logind by default goes berserk as a consequence of a laptop lid switch event (since my laptop is constantly docked, the lid is closed). Two thoughts about that, though. First of all, I also kept the lid closed with the nouveau drivers, and logind didn't behave in the same manner. So, something changed when I installed the Nvidia proprietary drivers. But, perhaps most important, I'm not sure I agree it makes sense for logind to behave that way, flood the logs, and end up consuming all available disk space on the root partition. All this brings up the issue, once again, of systemd. Yes, I know, it also has its advantages. By now, I've learnt to live with it, and it's OK. However, I don't like the fact that as an end user I have little choice but to run systemd, whether I like it or not. Yes, I know there are some distros out there that run without it. But they are, for the most part, to put it bluntly, fringe distros. I simply cannot run something like Devuan for work. In the end, the problem is that systemd is the proverbial monster with a thousand heads. It does too much for its own good. {link to this entry}