Category Archives: malfunctioning computers

MUA

today is the third day of NOT using Kontact, the MUA that i have been using pretty much ever since i switched to linux, back in the dark ages.

i really liked kontact. it did EXACTLY what i wanted it to do: it handled all of my email addresses in a logical way, made it easy to switch from one email address to another, worked well with my business set-up, my installation of sigrot

but it had a fatal flaw which i have been trying (and, mostly, succeeding) to work around for quite some time now, and that is its use of akonadi, which is the interface between the MUA and the SQL database that lives behind it.

for the first few years i didn’t even notice a problem, but then i upgraded my operating system, and everything blew up. i ended up installing the new operating system from scratch, and summarily trashing three or four years worth of collected email. it was a difficult process, but i got through it.

through the years, i have tried installing a number of MUAs, in order to try and get away from kontact, but either they didn’t do what i wanted, or they simply didn’t work at all, so i gave up and went back to fighting with kontact…

“the devil you know”, right?

after that, there were a number of times, primarily during updates or upgrades, when i had to battle with kontact/akonadi/SQL, to get it to work, and i had to trash a number of years of collected email at least one more time before reaching the point at which i am, now.

four days ago, i ran the operating system updates, and, after i was done, i tried starting up kontact, and nothing happened. i tried starting it from the konsole (rather than “clicking” on the “icon”, which is how you start it in the GUI), got a vaguely worded, cryptic message about being unable to start “hebrew.wgz.sizes.sonnet.plugins.hspell”, and then it hung up.

which is very odd, because i have never even installed the hebrew language pack, and have no idea why it would even be attempting to start the hebrew spelling dictionary…

i tried asking Kubuntu Forums for solutions, and got the same answer that i have gotten every OTHER time i have asked about how to fix kontact, which is “kontact is broken, install thunderbird instead”.

so i tried installing thunderbird (AGAIN), and, after having some “words” with my operating system about whether this new piece of software actually worked (or not), i successfully installed and more-or-less correctly configured it, and started using it.

it’s a little different than kontact… or, at least, my perception is that it is a little different than kontact. after some futzing around, i learned how to configure it to use more than one email address — actually, i may have done it “the other way” first, because the terminology for “accounts” and “identities” is slightly different on kontact — and, as far as i can tell, there is no easy way to add an “X-” header line to outgoing email, like there is in kontact, but that may just be because i have yet to find the place where such a thing is configured.

and, then, yesterday (after i had, more or less, given up on kontact), i discovered that kontact actually worked… it had been a few days since i had given up trying to start it, because of “hebrew.wgz.sizes.sonnet.plugins.hspell” not working, and, without thinking about it, i “clicked” on the “icon” and kontact sprang back to life!

so, the first thing i did was transfer all of my contacts, and most of my RSS feeds (i got bored and antsy, so i’ll finish them later) to thunderbird.

for some time, now, when i “quit” kontact (select “quit” from the “file” menu), i have had to go to the konsole, and “kill” the process that kontact was running, so that it would actually quit. i also discovered that “kill”ing kontact STILL allows incoming mail to be downloaded, a process that i don’t completely understand (it may have something to do with akonadi interacting with the POP3 mailserver).

also, for even longer (i recall at least two kontact upgrades that have had this behaviour, prior to the one i am currently (not) using), when i first start kontact, after booting up my computer in the morning, about 98.9% of the time it gets to the point where it’s displaying correctly on the screen, but before i have the chance to do anything, it puts up a dialogue box that says that there has been a fatal error and kontact will quit now. the dialogue doesn’t say what the fatal error is, and it only has an “OK” button, which makes everything disappear when i click it. under this circumstance, when i run “ps -u salamandir | grep kontact” in the konsole, kontact is, actually, not running (unlike when i select “quit” from the “file” menu), and if i restart kontact, it works without any further problems…

except that, sometimes (usually at least once a day), it freezes for anywhere from a few seconds to several minutes, and when it does, there’s a very good chance (greater than half the time) that it will crash. usually this happens when i have just selected a message to reply to, and/or usually it happens when it is in the process of downloading new mail or RSS feeds. sometimes i can anticipate when it’s going to happen, when i have to reply to a message and it is in the process of downloading.

thunderbird doesn’t have these problem. when i select “quit” from the “file” menu, in thunderbird, it actually quits, and doesn’t keep downloading mail anyway. thunderbird doesn’t crash for no reason, or freeze and crash. it may not be kontact, but on the other hand, it’s not kontact.

my impression is that the operating system struggles when there is more than one MUA running, and, because of the difficulties i’ve been having getting kontact to quit, i don’t like to keep both of them running for long periods of time, especially since, apparently, kontact’s interface with the POP3 mailserver takes precedence, even after i “quit” and “kill” it, and even when i start up thunderbird first (which it shouldn’t, but it goes to support the fact that “kontact is broken”).

ahhhh! now we find out…

my newly redesigned site uses the enfold theme, which has faulty (under certain circumstances) caching and optimisation routines, so we use lightspeed cache, which doesn’t have those (particular) faults, and works better (under certain circumstances).

except, last year, prior to my site being redesigned (when i was still using the avada theme), i was told (by SOMEONE) to disable lightspeed cache, because it had some sort of incompatibility with… something…

so, i went through the site redesign with a disabled lightspeed plugin. no problem, until i put in the enfold theme, and whatever circumstances that cause the caching and optimisation routines to fail, were happening, which was the cause of the first go-round.

turning on the lightspeed cache fixed the first go-round, but whatever incompatibility i was trying to avoid by having the lightspeed plugin disabled, took effect, which was the cause of the second go-round.

which was further confused by the fact that part of my routine for fixing the first go-round was good enough that it fixed the second go-round well enough that i didn’t find out about it until it was too late.

what i found out, today, via my web developer, is that the people who make the lightspeed cache and webhost python (my host provider) have their own battle going on: on webhost python’s servers (which include mine), the lightspeed plugin causes expired transients to multiply and duplicate. lightspeed says it’s python’s fault. python disagrees…

on the record…

OFF the record, python agrees that there is a bug in their system that they haven’t found yet… compounded by the fact that it was THEIR ERROR which caused the third go-round… 😠 but it’s not for me to say “i told you so”, especially with my already somewhat precarious position with this particular host provider…

and so, i’m caught in the middle. 😒

apparently, for the time being anyway, the plan is to disable the caching modules on both enfold AND lightspeed, keep an eye on the database (which hasn’t blown up since implementing this plan), clear the expired transients manually, and examine other options for a cache.

😒

oy! why won’t this just go away?

at midnight (which was 3:00 in the morning, florida time), i got a message saying that the database was blowing up again. they said it was 183 GIGABYTES

because of the fact that i was asleep (thankfully), i didn’t actually read the message until 7:00 my time (10:00 florida time). i immediately logged into my web server, and discovered that the MySQL disk usage was lower than i have ever seen it before, which is to say 253 MEGABYTES

what this tells me is that there’s something else going on besides this whole “enfold-theme-not-caching-correctly” horseshit.

which is bad.

it also tells me that, whatever it is, we haven’t actually found it… we may have found another problem, but not the one for which we’re looking… yet…

which is bad, but not as bad as it could be.

it also tells me that, whatever it is that is going wrong, the cronjob that we put in place to solve the problem, works, REGARDLESS of the actual problem.

which is good.

but, when it comes right down to it, it is not good for me to be so stressed out about something over which i have very little control.

which is bad.

something has to be done. this is ridiculous.

oh, but it couldn’t have ended there, now, could it?

and the answer is, a big, fat, OF COURSE NOT! 😒

i woke up this morning, and couldn’t log in to my web site… at, like, SEVEN in the fucking morning, i was wide awake because i couldn’t log in to my web site.

at NINE, the web designer gets back to me. he can’t login either. apparently the host provider has disabled the config file that makes everything work — i login using SSH, and there’s the file… everything LOOKS okay, but… the host provider apparently did SOMETHING to my web site. as far as i can tell, everything works, sort of, until you get one or two pages deep, at which point it gives me a “unable to connect to database” error.

😠

so, i file a ticket with the host provider. a couple hours later, (all the while, i’m sweating bullets) they get back to me, apparently, the database blew up AGAIN. they disabled the config file so that nobody could use the web site, because the database was growing by gigabytes A SECOND.

😠😠

eventually (seriously, they took most of the day to UN-disable the config file), the web designer went in and turned off everything having to do with the built-in, screwy, does-not-work, enfold caching and optimisation routines, turned OFF “store transients”, and set a cronfile to delete three rows of a table in the database, every hour.

😠😠😠😠‼‼‼

this better be the last of it for a while, because i’m just about ready to throw in the towel.

database update

the database is fixed. 😌

what happened? that’s complex.

recently, i had my web site redesigned. the new design uses the “Enfold” theme, which uses a lot of what they call “transients” to maintain the look and feel of the site, regardless of the platform on which it’s being viewed. “transients” are sort of like cookies, except that you can’t opt out of them, and they don’t contain any personally identifying information. some of these “transients” expire immediately when a person leaves the web site, and others persist, for a few minutes to several days. they persist on your computer AND on my server… in the one of the tables in the database…

the “Enfold” theme has automatic caching and garbage collection routines that are supposed to handle these expired “transients”, but, because it’s a wordpress theme, it doesn’t do all the jobs very well… or, sometimes, at all… which is why i also use a caching plugin that actually, you know, works ALL the time, and not only some of the time… 😒

except that, for some reason, prior to my site upgrade, “someone” (and i have yet to identify who, but it was either my web designer or my host provider) recommended that i disable the caching plugin, because of some issue with the new version of wordpress… or something like that… as i said, i don’t remember. i distinctly remember disabling the plugin on someone’s recommendation, i just don’t remember exactly who, when or why. 😖

one way or the other, my caching plugin was disabled, which meant that, when i installed the new theme, it was relying on the not-working-the-way-it-should, internal cache… which, basically, didn’t work, causing the table in the database to expand beyond my disk space allocation. 🤯

it didn’t show up in my cPanel because i wasn’t looking at the SQL disk space, which is “below the fold” of my browser, and i just didn’t scroll down far enough to see it. 😕 during the nightly automatic backup, it was overwhelming the server for everybody, not just me. i had to pay my web designer for two days of poking through piles of arcane SQL code and deleting bits and pieces of it. it was not fun.

the solution was to enable the caching plugin(!), and to install a “transient manager” plugin, so that i can delete the expired transients from the wordpress dashboard, and not from the SQL database,… which requires A LOT more “knowing what to look for” and “knowing how to delete stuff without damaging other stuff” than i have on board, personally.