All my desktop and laptop computers are Linux-based, more specifically, being Debian-based, but I enjoy having some of the simplifications which Windows offers, including either to notify me of pending updates, so that I can use point-and-click methods to install those, or even, in some cases, to install updates automatically. The package which I use, to install updates automatically, as I sleep, is called ‘unattended-upgrades’, which is a package which cannot simply be installed and forgotten. If the user has installed this package, he or she must also configure it. And the following Web-article explains, how to do so under Debian:
A situation I was having for some time was, that ‘unattended-upgrades’ was installed and working fine, on my Debian / Jessie – aka Debian 8 computer named ‘Phoenix’, but that even though I had followed all the instructions for how to install and configure it on my Debian / Stretch – aka Debian 9 computer named ‘Phosphene’, the same package did not seem to work on that one. I had often found that if there did exist updates which the automated process was supposed to install, then the log file on ‘Phosphene’ would break off, just before indicating which packages were going to be installed, and no updates would take place. This would happen every time that some updates were to be installed, and required each time, that I install the updates in question manually. Also, the ‘normal’ logging output did not include any error messages; it would simply stop in mid-process.
What I finally needed to do in order to troubleshoot this process, was to wait until there were going to be pending updates, and then, instead of installing those manually, to run the following command from the command-line, as root, and to observe the output:
# unattended-upgrades -d
Running this command when there were no updates pending was rather useless, because the malfunction would not take place, unless there were updates pending. Also, this process should not be interrupted if it’s in the middle of installing updates, because doing so can and will cause package-corruption and / or software corruption. If the process is going to install multiple packages, the user needs to wait until that process has finished, before doing anything else from the same command-line. What I finally found was, that the article linked to above omits a very important piece of information.
Every line in the configuration file, which blacklists a certain package from being updated, is treated as a regular expression. Regular expressions are a powerful tool under Linux, that allows a string to match a wide variety of patterns, using a specific syntax, but that does not require that every pattern which will match, be defined separately. The thing with regular expressions is that users need to be told, whenever text is supposed to define a regular-expression pattern, and not just represent an exact line of text.
And so what I had been doing on the computer named ‘Phosphene’, but not on the computer named ‘Phoenix’, was to state certain package-names, that contained plus-signs (‘+’), because certain package-names do. However, the plus-sign is also a special character when defining patterns using regular expressions, and when placed at random inside a text string, can form a malformed regular expression, which in turn can cause the Python script to crash, which is parsing the configuration file, and when that script is trying to determine which of the available upgrades it’s allowed to install.
My solution to this problem was simply, to remove any package-names from the black-list, that were to contain plus-signs, and the ‘unattended-upgrades’ package now works fine.
Alternatively, there is a way to escape-code the plus-sign, so that Python will not interpret them as having a special meaning, but so that the escape-sequence will just match one plus-sign. I did not bother to do that.