Analyse "queuednotification" memory_limit

This procedure should help you determine which ticket/object in GLPI is causing a CRITICAL memory_limit issue when the queuednotification automatic action runs.

---

Example error in php-errors.log

[2026-07-17 04:00:09] glpi.CRITICAL:   *** Fatal Error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 9269800 bytes)
  Backtrace :
  ./src/DBmysql.php:596                              

[2026-07-17 09:38:27] glpi.CRITICAL:   *** Uncaught PHP Exception Symfony\Component\ErrorHandler\Error\OutOfMemoryError: "Error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 4775392 bytes)" at DBmysql.php line 596
  Backtrace :
  ./src/DBmysql.php:596

These SQL queries should be run against the GLPI database that is throwing the error.

---

Overview: total size of the queue (queuednotification)

SELECT COUNT(*) AS nb,
       ROUND(SUM(LENGTH(COALESCE(body_html,''))+LENGTH(COALESCE(body_text,'')))/1048576,1) AS total_mb,
       MAX(sent_try) AS max_retry
FROM glpi_queuednotifications WHERE is_deleted = 0;

Interpretation

• nb = how many emails are pending (a queue that keeps growing is a symptom).
• total_mb = raw cumulative weight of all HTML/text bodies (if this runs into hundreds of MB, it's consistent with hitting the memory_limit).
• A high max_retry (>3-5) indicates emails that keep failing in a loop and get picked up again in the batch on every cron run, which makes the underlying problem worse.

Concrete example of a worrying result:

---

The 20 largest pending notifications

SELECT id, itemtype, items_id, event, recipient, sent_try, create_time,
       ROUND(LENGTH(COALESCE(body_html,''))/1048576,2) AS html_mb
FROM glpi_queuednotifications
WHERE is_deleted = 0
ORDER BY LENGTH(COALESCE(body_html,'')) DESC LIMIT 20;

Interpretation

• html_mb: if one or more rows are several MB (5-15 MB), the associated items_id is very likely the cause of the error.
• itemtype/items_id: gives you the ticket (or other object) at fault to go inspect.

Concrete example of an abnormal result for items_id 5557:

---

Which ticket/object generates the most volume (body × recipients)

SELECT itemtype, items_id, event, COUNT(*) AS nb_dest,
       ROUND(SUM(LENGTH(COALESCE(body_html,'')))/1048576,1) AS mb
FROM glpi_queuednotifications
WHERE is_deleted = 0
GROUP BY itemtype, items_id, event
ORDER BY mb DESC LIMIT 10;

Interpretation

• A high nb_dest (10, 20, 30...) combined with a high mb = strong likelihood that this items_id is causing the error.

Concrete example of an abnormal result for items_id 5557:

---

Simulating the next cron batch

SELECT ROUND(SUM(LENGTH(COALESCE(body_html,''))+LENGTH(COALESCE(body_text,'')))/1048576,1) AS mb_next_batch
FROM (SELECT body_html, body_text FROM glpi_queuednotifications
      WHERE is_deleted = 0 AND mode = 'mailing' AND send_time <= NOW()
      ORDER BY send_time ASC LIMIT 50) q;

Interpretation

• If mb_next_batch exceeds roughly 100-150 MB, the next cron run will likely crash again (the multiplying effect of the buffered mysqli result plus the PHP copy can triple this figure in actual memory usage).
• If the result is low but the crash persists, it's a sign that the batch has changed between two runs (new emails arrived, or sent_try caused other rows to resurface) — rerun the query right before/after the crash to compare.

Concrete example of an abnormal result:

---

Inspecting the offending ticket

Once the candidate ticket for the crash has been identified via SQL, you can go inspect it right away (in SQL or the UI) — there's a good chance the problem will be immediately obvious. Example here with +6000 followups (it can also be very heavy images in followups/descriptions):

That many followups is typical of an auto-reply loop: a sender with an autoresponder (out-of-office, marketing email, read receipt...) replies to every GLPI notification, the mail receiver turns each reply into a followup, which triggers a new notification, which in turn causes another automatic reply, and so on.

Each new followup re-embeds the entire quoted history, which is why notifications end up several MB in size and eventually blow up the cron's memory.

---

Cleaning up the ticket

With thousands of followups, deleting via the interface also risks exceeding the memory_limit.

So the followups are deleted directly in the database first:

First check the volume:

SELECT COUNT(*)
FROM glpi_itilfollowups
WHERE itemtype = 'Ticket' AND items_id = <DETECTED_TICKET_ID>;

Then delete:

DELETE FROM glpi_itilfollowups
WHERE itemtype = 'Ticket' AND items_id = <DETECTED_TICKET_ID>;

Once the followups have been purged, the ticket becomes manageable again in the interface: put it in the trash and then permanently purge it from GLPI (not via SQL), so that GLPI properly cleans up all related data (actors, documents, queued notifications...).

You should also remember to purge any notifications still pending for this ticket if the queue queries still show some.

---

Cleaning up the mail receiver

Connect to the mailbox used by the receiver and delete the remaining loop emails (including in any configured archive/reject folders).

Without this, the next receiver run will re-import the messages and the loop could potentially start again.

---

Adjusting the receiver's rules engine

In Administration > Rules > Rules for assigning a ticket created through a mails receiver, check that the default rules for rejecting automatic replies are enabled, and supplement them as needed based on the case encountered.

Useful criteria:

• an Auto-Submitted header different from no (RFC 3834 standard, covers most autoresponders);
• X-Auto-Response-Suppress or X-Autoreply headers present;
• sender addresses such as no-reply@, newsletter@, mailer-daemon@...;
• subject line containing the patterns observed in the loop (in our example, a recurring marketing subject).

The associated action: reject the ticket without notification (especially not an automatic rejection reply, which would restart the loop).