Unattended Upgrades Resumed Running Normally Again, This Morning.

In This earlier posting only yesterday, I had written that for an unknown reason, my unattended upgrades not only did not run automatically, but that the responsible ‘cron.daily‘ script refused to run them, when invoked manually as root.

Well today, the unattended upgrades ran normally again, and also installed numerous updates. Routinely, without apparent errors.

Dirk

 

Unattended Upgrades Did Not Run This Morning.

I have had the strange experience, that this morning, for reasons unknown, my unattended upgrades system did not run, not even leaving an entry in any of its log files.

Additionally, running the script manually as root:

 


/etc/cron.daily/apt


 

Simply reproduces the behavior, of the updates not running.

But, I have noticed that This has happened to me once before. Strangely, the last time this happened was on March 14, 2016. This is usually around the time of year that Daylight Savings Time begins, and DST began this past Sunday, which was yesterday.

If this is somehow a DST bug, then I find it most strange, that it would not affect the Sunday in question, but the following Monday.

I will continue to monitor this problem. In 2016, the malfunction simply evaporated by the next day.

(Edit 03/14/2017 : )

Continue reading Unattended Upgrades Did Not Run This Morning.

How I fixed my Chrome for Linux Package Issue

In a previous posting, I described a specific issue I was having, with my Linux installation of Google Chrome.

I have now found a solution to this exact problem.

Chrome for Linux installs a daily cron job, which resets the file

/etc/apt/sources.list.d/google-chrome.list

by default. If it is absolutely necessary to override this behavior, let us say because our package manager is set up by default to pull both the 32-bit and the 64-bit contents of any repository, but the latest build of Chrome only supports a 64-bit architecture, then there is a configuration file named

/etc/default/google-chrome

This file defaults to containing


repo_add_once="false"
repo_reenable_on_distupgrade="true"

This can be changed to


repo_add_once="true"
repo_reenable_on_distupgrade="true"

Dirk

(Edit 02/06/2016 : ) Unfortunately, I have discovered that the variables defined in

/etc/default/google-chrome

Do Not change the behavior of the cron job, to rewrite the file

/etc/apt/sources.list.d/google-chrome.list

And so I found that slightly more aggressive editing was needed by be.

On standard Debian / Linux systems, the daily cron jobs associated with specific packages are stored in the directory

/etc/cron.daily

And there is a symlink in this directory, pointing to a target file, which is the script that Google Chrome runs. I did not take out the symlink. But I have changed the permission bits of the target file, to make that non-executable.