Critical Error - [0100]

[perte]

After running Sentora (1.0.3) for a couple of years, it started to stop working from time to time, without knowing what triggers the Critical Error - [0100]. 

I know when Sentora isn't running only when I don't get emails. 

The quick fix that I found is to do a sudo reboot.

Is there something I can do to fix this?

[TGates]

First thought is HD space. If your logs or clients are using more disk space then your HD can handle it will shut down.
If Sentora has been working for years without problems, disk storage space is the first thing to check.

Log files in general can eat up a lot of space.

You also need to check which log files are so big. A client may have a 'bad' website that is posting a lot of errors to the logs making them grow fast.

[perte]

First thought is HD space. If your logs or clients are using more disk space then your HD can handle it will shut down.
If Sentora has been working for years without problems, disk storage space is the first thing to check.

Log files in general can eat up a lot of space.

You also need to check which log files are so big. A client may have a 'bad' website that is posting a lot of errors to the logs making them grow fast.

Just checked and it's not that. The problems started after I installed AnchorCMS on one of the sites. Could one database be corrupted? 


http://snpy.in/28E1ri

[betatester3.0]

Just checked and it's not that. The problems started after I installed AnchorCMS on one of the sites. Could one database be corrupted? 


http://snpy.in/28E1ri

try removing all db entries from AnchorCMS & remove the CMS completely. then check if you are still getting Error: "0100".

If you still are, check all clients logs, check server logs, check all available logs. That should determine what is casing the issue or direct you to a users site that is giving those errors.

[perte]

So, I've been checking the MySQL logs recently and found this:

PHP Code:

171004 13:37:22 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
171004 13:37:22 [Note] Plugin 'FEDERATED' is disabled.
171004 13:37:22 InnoDB: The InnoDB memory heap is disabled
171004 13:37:22 InnoDB: Mutexes and rw_locks use GCC atomic builtins
171004 13:37:22 InnoDB: Compressed tables use zlib 1.2.8
171004 13:37:22 InnoDB: Using Linux native AIO
171004 13:37:22 InnoDB: Initializing buffer pool, size = 128.0M
171004 13:37:22 InnoDB: Completed initialization of buffer pool
171004 13:37:22 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
171004 13:37:22  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
171004 13:37:22  InnoDB: Waiting for the background threads to start
171004 13:37:23 InnoDB: 5.5.44 started; log sequence number 802606510
171004 13:37:23 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
171004 13:37:23 [Note]   - '127.0.0.1' resolves to '127.0.0.1';
171004 13:37:23 [Note] Server socket created on IP: '127.0.0.1'.
171004 13:37:23 [Note] Event Scheduler: Loaded 0 events
171004 13:37:23 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.44-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
171004 13:37:24 [ERROR] /usr/sbin/mysqld: Table './sentora_core/x_bandwidth' is marked as crashed and should be repaired
171004 13:37:24 [Warning] Checking table:   './sentora_core/x_bandwidth' 


Coincidentally, I stopped getting emails after 13:30 - that's how I know my server is down. So I assume that there's something wrong here, right?