Large ispconfig.log locks up the server

Hello,
I`ve noticed a few times that some times the /var/log/ispconfig/ispconfig.log grows above 1 GB.
The cronjob then consumes 100% CPU for a long time (i guess it tries to read the log file).
My solution was to rename the ispconfig.log and create an empty file.
My solution to prevent this issue is just to use monitoring software to monitor the filesize of the log.
I guess i`m the only one with the issue. But i still want to share the problem.
Maybe it helps someone in the future, or maybe a check can be made to rotate the log file when i becomes larger then 1 GB.

Greetings,

 

Hello Till,

Yeah it does.
Not sure why. But the last time there where hardware failures. So i blamed it on that.

I`ve just grepped a few lines from it. And it contains something like this:
28.06.2017-22:32 - WARNING - Falsche Anfrage / Wrong QuerySQL-Query = INSERT INTO sys_log (server_id,datalog_id,loglevel,tstamp,message) VALUES (1, 0, 1, UNIX_TIMESTAMP(), 'Falsche Anfrage / Wrong QuerySQL-Query = INSERT INTO sys_log (server_id,datalog_id,loglevel,tstamp,message) VALUES (1, 0, 1, UNIX_TIMESTAMP(), \'Falsche Anfrage / Wrong QuerySQL-Query = INSERT INTO sys_log (server_id,datalog_id,loglevel,tstamp,message) VALUES (1, 0, 1, UNIX_TIMESTAMP(), \\\'Falsche Anfrage / Wrong QuerySQL-Query = INSERT INTO sys_log (server_id,datalog_id,loglevel,tstamp,message) VALUES (1, 0, 1, UNIX_TIMESTAMP(), \\\\\\\'Falsche Anfrage / Wrong QuerySQL-Query = INSERT INTO sys_log (server_id,datalog_id,loglevel,tstamp,message) VALUES (1, 0, 1, UNIX_TIMESTAMP(), \\\\\\\\\\\\\\\'Falsche Anfrage / Wrong QuerySQL-Query = INSERT INTO sys_log (server_id,datalog_id,loglevel,tstamp,message) VALUES (1, 0, 1, UNIX_TIMESTAMP(), \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'Falsche Anfrage / Wrong QuerySQL-Query = INSERT INTO sys_log (server_id,datalog_id,loglevel,tstamp,message) VALUES (1, 0, 1, UNIX_TIMESTAMP(), \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'Falsche Anfrage / Wrong QuerySQL-Query = INSERT INTO sys_log (server_id,datalog_id,loglevel,tstamp,message) VALUES (1, 0, 1, UNIX_TIMESTAMP(), \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'

And a lot of this:
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Hope you can make something from it.

Greetings,
Johan Toonders

 

You're not possibly using a drbd partition or a seperate hdd/patririon to store the mysql directory? I hade the same problem that the log would eat up all my space in a few days. It happend because the partition that should been mounted into my mysql folder was inactive/ not mounted. So the ispconfig scripts that run every minute from crontab can't execute the querys.
I fixed it so that I made a script that runs the ispconfig scripts only if the needed partition is mounted.
Or it can be a permission problem, that the mysql directory has wrong permissions or owners.

 

Hello Till,
I`m using version 3.1.2.
Might be correct that mysql-server was unavailable at that time because of the hardware error.

@Tomislav Aurednik i`m not using mysql on any different partition.

Greetings,
Johan Toonders