Hi @zebulon,

There are several causes that may lead to a table crash, and there is also a lot of documentation about it in the internet, but almost everybody remarks the same causes.

1) Do you prune your hitlog table in a regular basis? What size is that table?
2) Do you have enough available resources to deal with your daily traffic? I mean, hard drive space, RAM, CPU.
3) Is the server in a good shape? Faulty hardware is not a good idea.
4) Is the server unproperly restarted?

Also, you may find that evo_hitlog is a MyIsam table, so changing it to InnoDB could make it more reliable, but you may feel the difference in performance. This post from our manual explains this point a little more: http://b2evolution.net/man/myisam-vs-innodb

Hi @mgsolipa

1) I left everything at the default
2) It is not in full production at this moment - still in de setup for use in our company
3) Its running on a vm esx server, virtual maschine is a openSuSE 13.1 Linux, 2 CPU, 4GB RAM, 15 GB free space, apache2 2.4.6, MariaDB 10.0.17, php 5.4.20
There are no server issues. Gets regular updates and restarts between 2 - 7 days.
4) no

The table is not that big, appox 900kb

I started with a test to convert te table to InnoDB and back to MyISAM - just to see what happens next. If the fault is still there I will test if changing to InnoDB will help.

I will let you know.

Regards

Ok
My first action did not help - I have truncated the hitlog table and now at least I do not get this error anymore.
So I thought to setup scheduled jobs to better prevent this issue...

...but I now have tried to set up the scheduled jobs and cannot get it to work.
I have a working cron job on the Linux server but the output always is that there is no scheduled job - though they are and they are in the database.

I had a look into this subject in de DOC section but can't find anything that I did wrong,

Can someone assist with this please?

How are you setting the scheduled job? Did you consider the "Planned at" column? It means the task will be executed by the cronjob on its first call after that time mark. If nothing is planned, the script will keep returning the "no task to execute yet" message.

O.k.

The mysql error is gone because I truncated the table with phpMyAdmin.

I also found out why my cron jobs would not work (while waiting for it to execute for test):

For some reason - not clear to me - the Linux server cron job gets executed at UTC time; whereas the server time, php/b2evoltution time is Europe/Amsterdam - which is 2 hours ahead of UTC.

In practice this means that I have to schedule a cron job at '01:00:00' if I want it to be executed at '03:00:00'

Some info on the internet suggest to put 'CRON_TZ=Europe/Amsterdam' before the cronjob - but this seems not to be the solution for the time difference.

Some people say that the cronjob may be set to take the server's hwclock, so the timezone configuration is overridden. Others also suggest to restart the cron service with # service cron restart (don't know if that's how the service is restarted in your openSuSe).

Now that I know what the problem was I can live with the UTC time execution times.
I did reseach the cron times as well but could not find a working solution.
I do know how to start/stop en check the services.

For the moment I'm fine with this...

Thanks

Hi

Just to let you know that I found the issue with the cron job executed at 'UTC' time.

Actually there are 2 php.ini files in the openSuSE server.

One is located in /etc/php5/apache2/php.ini
the other is in /etc/php5/cli/php.ini

In both ini files one has to set the correct time zone. In my case the one in the cli folder was still on 'UTC'

Regards.

Niltze, all!

I came to this specific post in the forum because of the crashed evo_hitlog table issue that started this thread.

I, as well, recently upgraded one b2evolution instance to MariaDB 10.0.17.

Basically I repaired the table as:

mysqlrepair -u root -p b2evo-database-name evo_hitlog

Nevertheless, I get the following issue when executing cron_exec.php manually.

From a bash prompt at Debian:
--------------------------------------------------------------------------------------------------------
/usr/bin/php /path/to/b2evolution/cron/cron_exec.php

Requesting lock on task #7 [Prune old hits & sessions (includes OPTIMIZE)]

Starting task #7 [Prune old hits & sessions (includes OPTIMIZE)] at 15:27:54.

Task finished at 15:27:54 with status: error
Message: [Error code: 2 ] Auto pruning is not set to run as a scheduled task
------------------------------------------------------------------------------------------------------------

If the "prune old hits and sessions" job is listed at the Scheduler tab and has ID xy at the back office, what am I missing by doing it from the server bash command prompt?

Insight appreciated in advance.

Hi @nanahuatl,

Auto pruning must be set in the back office to run with a scheduled job. More information in this page: http://b2evolution.net/man/hit-logging

Regards!