cron job | Dirk Mittler's Blog

An Update on how the Object Cache works, in WordPress

In this earlier posting, I had added comments that describe caching in general, as well as the Object Cache of WordPress, without really knowing how the latter works in detail, because I have never written a WordPress plug-in.

There was a fact which I had never mentioned, that in the caching daemon, each Key-Value Pair has a time-stamp, indicating exactly when the Value was set. Apparently, when plug-in designers query the MySQL database, they have the option to make that a cached query, which means that the query will first query the cache, and only if there is no Value in the cache, will query the database.

This query has as optional parameter, an expiry time, so that if the Value in the cache is older than this time, it will be regarded as not being in the cache.

I suppose this is useful in certain cases, where there is no opportunity to delete the Key in the cache when data is updated, but in which to view a widget simply looks up some value in the database, which could be cached.

I have communicated with the author of Post Views Counter, who has told me that he has in fact modified his plug-in, to add an expiry value to his cached queries, to try to solve the problem of data-views not updating, since the last plug-in update. And I have also installed the latest version of his plug-in, which contains his patch.

I suppose that one question this revelation raises, is whether it is in fact a part of what gets cached, pieces of HTML that constitute whole postings, at the request of core PHP code. It may not be. Instead, it may only be the case that HTML continues to be generated by PHP code, on the basis of database queries, but that more of those queries may be cached queries now.

However, the actual HTML of which my postings consist, is obtained by queries to the database.

Dirk

Note: The patch which this plug-in author has applied to his code, does in fact work, and I can safely delete the cron-job which I had created as a workaround.

Continue reading An Update on how the Object Cache works, in WordPress

Why Android Devices Consume More Power, Until They Are Rebooted

One of the many misconceptions which people have about Android, is that it is another flavor of Linux, because it uses the Linux kernel. Android is not Linux, and for that reason, also does not have ‘cron’. cron is a Linux daemon, which allows for the background scheduling of services, that are kept in non-volatile memory. Android does not have this.

The background scheduler which Android uses, is based 100% in volatile memory. What this means is that a given app needs to have run at least once in any given session – i.e. since the last reboot – in order to place an ‘Alarm’ in the background scheduler, for itself to be woken again, according to the clock of the Android device.

This fact can confuse people, because additionally, certain apps have it as their privileges, that a part of themselves should be run once, when our Android device first boots. I.e., if the programmer decides that his app should run in the background, even if a user has never launched it, then he must first arrange to have a part of that app run once, every time the device boots, so that that part of the app can register scheduled re-awakenings of itself afterward.

But what that also means, is that if a user has 200 apps installed as I do, only some small subset of those are set to run when the device is rebooted. Facebook and Twitter happen to be among those. But after that, as I run more and more of my apps in a given session, more and more alarms get registered, so that the device is in standby potentially less and less, and so that my battery consumption also gets worse.

Further, many people like for their apps to give them push notifications. Well, as we run these additional apps, they also re-register with whatever server they are supposed to receive push notifications from, which means that the apps are receiving more push notifications as the session continues. And then our CPUs stay in low-power mode for less and less time.

So it is a good idea, to reboot our devices from time to time, for a number of reasons, not just for the reason I explained here.

Also, Android has a separate list of Accounts, that are specifically listed in the System Settings. Android will make sure when it boots, that all the accounts there which are set to sync, are in fact registered. A longer list of accounts also means greater battery consumption. In fact, I am sure that Android will periodically rescan the accounts there, to make sure that their connection to the server is ‘alive’, as our device disconnects from and reconnects to the network.

Dirk

Monthly Log Rotation Disrupted my IPv6 Today.

One of the tasks which a Debian / Linux system does, is log-rotations at regular intervals. Some log-rotations take place daily, others weekly, and others monthly.

When log files are rotated, the services that generate them must usually be restarted, although there are a very few daemons which can simply be commanded to reopen their log file. This needs to be done, because even when the name of the log file has been changed (by the log-rotation), the file handle which its process has, still points to the same file. So most generally, the service is also restarted, so that it can open a new log-file, with the name of the old log-file, which was rotated to having a new file-name.

I have two services installed, to which this is relevant today. One of them is my “OpenVPN Server”, and the other is my “Teredo Client”. The Teredo Client was already configured by package maintainers, not to do any log-rotations. But my OpenVPN Server does a log-rotation on a monthly basis.

One of the facts about how my system reacts is in practice, that when my OpenVPN Server does a restart, it also incapacitates my Teredo Client. I am not sure why this happens, but it is completely consistent behavior. It has something to do with how my dual-stack kernel manages its IPv6 addresses.

So today, being July 1, saw a log-rotation to my OpenVPN Server, which also took out my Teredo Client, at the time the monthly log-rotations are supposed to take place, in a 100% predictable manner. I needed to restart the Teredo Client, in order to get my IPv6 address back, by about 14h15 this afternoon. From about 6h00 until 14h15 today, this site had no working IPv6 address.

I apologize for any inconvenience.

Dirk

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.