• Debian 11 is approaching its end-of-life (vendor EOL date - August 31, 2026). Plesk Obsidian 18.0.80 will be the last release to support it.
    If you are running Plesk Obsidian on Debian 11, we recommend you upgrade those servers to Debian 12 using our dist-upgrade tool.
  • We plan to deprecate and remove the support for XML RPC protocol versions earlier than 1.6.9.1 in Plesk Obsidian 18.0.82. We strongly recommend that you update all existing integrations using earlier versions of the XML RPC protocol to comply with the version 1.6.9.1 specification.

Issue Plesk extension/email-security

Jürgen_T

Regular Pleskian
Server operating system version
Ubuntu 22.04.5 LTS
Plesk version and microupdate number
Plesk Obsidian v18.0.66_build1800241218.14
Suddenly I get every full hour the following error message:

SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'email' at row 1, query was: REPLACE INTO `stats_accounts`
SET `email` = :email
, `receivedHam` = :receivedHam
, `receivedSpam` = :receivedSpam
, `receivedViruses` = :receivedViruses
, `sentHam` = :sentHam
, `sentSpam` = :sentSpam
, `sentViruses` = :sentViruses

Anybody any idea?
 
It started on 31st of December at 11 o'clock when this cronjob is performed:
Die Aufgabe "/opt/psa/admin/bin/php -dauto_prepend_file=sdk.php '/opt/psa/admin/plib/modules/email-security/scripts/update-stats.php'" wurde in 1 Sekunden abgeschlossen, jedoch traten Fehler auf
[2025-01-03 21:28:00.216] 86124:6778485034938 ERR [extension/email-security] SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'email' at row 1, query was: REPLACE INTO `stats_accounts`
SET `email` = :email
, `receivedHam` = :receivedHam
, `receivedSpam` = :receivedSpam
, `receivedViruses` = :receivedViruses
, `sentHam` = :sentHam
, `sentSpam` = :sentSpam
, `sentViruses` = :sentViruses

Since this time every hour.
 
Up to now every hour the corresponding cron-task for Plesk Email Security extension stops with the error as mentioned above. Please advice a.s.a.p
 
So, i tried to solve it by myself. The plesk db contains the table
MariaDB [emailsecurity]> DESCRIBE stats_accounts;
+-----------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------+--------------+------+-----+---------+-------+
| email | varchar(150) | NO | PRI | NULL | |
| receivedHam | int(11) | NO | | NULL | |
| receivedSpam | int(11) | NO | | NULL | |
| receivedViruses | int(11) | NO | | NULL | |
| sentHam | int(11) | NO | | NULL | |
| sentSpam | int(11) | NO | | NULL | |
| sentViruses | int(11) | NO | | NULL | |
+-----------------+--------------+------+-----+---------+-------+
7 rows in set (0.002 sec)

With " ALTER TABLE stats_accounts MODIFY email VARCHAR(512);" I have enlarged the field email to 512:

MariaDB [emailsecurity]> ALTER TABLE stats_accounts MODIFY email VARCHAR(512);
Query OK, 2135 rows affected (0.055 sec)
Records: 2135 Duplicates: 0 Warnings: 0

MariaDB [emailsecurity]> DESCRIBE stats_accounts;
+-----------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------+--------------+------+-----+---------+-------+
| email | varchar(512) | YES | UNI | NULL | |
| receivedHam | int(11) | NO | | NULL | |
| receivedSpam | int(11) | NO | | NULL | |
| receivedViruses | int(11) | NO | | NULL | |
| sentHam | int(11) | NO | | NULL | |
| sentSpam | int(11) | NO | | NULL | |
| sentViruses | int(11) | NO | | NULL | |
+-----------------+--------------+------+-----+---------+-------+
7 rows in set (0.004 sec)

Now the cron-job works again:

Die Aufgabe "/opt/psa/admin/bin/php -dauto_prepend_file=sdk.php '/opt/psa/admin/plib/modules/email-security/scripts/update-stats.php'" wurde erfolgreich in 1 Sekunden abgeschlossen.

However, please check, whether this approach is really applicable and will also work once the Plesk EMail Security extension get an update!
 
The cron most likely fails because the tables are storing too much data for the update process. Could you please set the varchar value back to the original one and try the workaround from this article instead?
 
Back
Top