Mailgate task stuck

[eduardomozart]

Code of Conduct

• I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• I have searched the existing issues

Version

10.0.7

Bug description

Hello,
When the mailgate task is triggered, sometimes it get stuck. Sometimes took a day, a week or month, but it get stuck again eventually. For me, it seems that the mail server is the culprit because it's slow, even when browsing mails through Webmail. But GLPI should be able to handle those laminas library exceptions and close the DB lock as expected, so when running the mailgate task again into the future when the mailserver is available again it should pull the messages instead of getting stuck and not running the mailgate task anymore. We have to go to the Actions page, click on "X" on "Running" task status of mailgate to make it scheduled again.

It doesn't seems that the task is reaching PHP/IIS request limit, and it's running a GLPI task instead of a CLI one, so it should be respecting PHP timeout and unlocking the task even when ended prematurely. I'm not sure, but maybe it's getting locked because it uses the same DB as queuednotifications or because it got stuck itself because laminas library failed? This error already shown into the past and it seems that when queuednotification is running and mailgate task is triggered, it seems more prone to this issue.

I'm facing this kind of issue for at least two years, and I'd have the opportunity to chat with cedric-ane and trasher about this. While talking to them, they'd said that GLPI tasks code doesn't seem to properly handle task execution failures, so the mailgate task get locked/stuck. We're running GLPI on Windows Server now, but I was already able to face this issue on Linux as well.

I do not believe this specific issue is related with attachments (as can be seen on #7327) because no pending mail message has attachments on it's receiver mail account, and when pulling mails manually it pulls the messages as expected.

Relevant log output

cron.log:


2023-05-04 11:16:31 [901@UNIFI]
Interno #1: Executar mailgate
2023-05-04 11:17:01 [901@UNIFI]
An error occurred trying to connect to collector.<br/>cannot read - connection closed?
2023-05-04 11:17:49 [901@UNIFI]
An error occurred trying to connect to collector.<br/>cannot read - connection closed?
2023-05-04 11:18:00 [@UNIFI]
Can't get DB lock

php-errors.log when collecting through mailgate task:

[2023-05-04 11:17:49] glpiphplog.CRITICAL:   *** Uncaught Exception Laminas\Mail\Protocol\Exception\RuntimeException: cannot read - connection closed? in C:\inetpub\glpi\vendor\laminas\laminas-mail\src\Protocol\Imap.php at line 110
  Backtrace :
  ...\laminas\laminas-mail\src\Protocol\Imap.php:125 Laminas\Mail\Protocol\Imap->nextLine()
  ...r\laminas\laminas-mail\src\Protocol\Imap.php:87 Laminas\Mail\Protocol\Imap->assumedNextLine()
  ...r\laminas\laminas-mail\src\Storage\Imap.php:223 Laminas\Mail\Protocol\Imap->connect()
  src\Toolbox.php:2193                               Laminas\Mail\Storage\Imap->__construct()
  src\MailCollector.php:1404                         Toolbox::getMailServerStorageInstance()
  src\MailCollector.php:698                          MailCollector->connect()
  src\MailCollector.php:1894                         MailCollector->collect()
  src\CronTask.php:1018                              MailCollector::cronMailgate()
  front\cron.php:63                                  CronTask::launch()

The error on php-errors.log seems to be slightly different when attempting to collect mails manually through "Receivers page":

[2023-05-04 11:30:30] glpiphplog.CRITICAL:   *** Uncaught Exception Laminas\Mail\Protocol\Exception\RuntimeException: cannot read - connection closed? in C:\inetpub\glpi\vendor\laminas\laminas-mail\src\Protocol\Imap.php at line 110
  Backtrace :
  ...\laminas\laminas-mail\src\Protocol\Imap.php:137 Laminas\Mail\Protocol\Imap->nextLine()
  ...\laminas\laminas-mail\src\Protocol\Imap.php:256 Laminas\Mail\Protocol\Imap->nextTaggedLine()
  ...\laminas\laminas-mail\src\Protocol\Imap.php:279 Laminas\Mail\Protocol\Imap->readLine()
  ...\laminas\laminas-mail\src\Protocol\Imap.php:344 Laminas\Mail\Protocol\Imap->readResponse()
  ...\laminas\laminas-mail\src\Protocol\Imap.php:781 Laminas\Mail\Protocol\Imap->requestAndResponse()
  ...r\laminas\laminas-mail\src\Storage\Imap.php:269 Laminas\Mail\Protocol\Imap->expunge()
  src\MailCollector.php:1863                         Laminas\Mail\Storage\Imap->removeMessage()
  src\MailCollector.php:960                          MailCollector->deleteMails()
  front\mailcollector.form.php:103                   MailCollector->collect()

Page URL

No response

Steps To reproduce

No response

Your GLPI setup information

Instruções de instalação e configuração

GLPI 10.0.7 ( => C:\inetpub\glpi)
Installation mode: TARBALL
Current language:pt_BR

Server

 

Operating system: Windows NT UNIFI 10.0 build 17763 (Windows Server 2016) AMD64

PHP 7.4.33 cgi-fcgi (Core, PDO, Phar, Reflection, SPL, SimpleXML, Zend OPcache, apcu, bcmath, bz2, calendar, cgi-fcgi, ctype,

curl, date, dom, exif, fileinfo, filter, gd, hash, iconv, imap, intl, json, ldap, libxml, mbstring, mysqli, mysqlnd, openssl,

pcre, readline, session, sodium, standard, tokenizer, xml, xmlreader, xmlwriter, zip, zlib)

Setup: max_execution_time="600" memory_limit="256M" post_max_size="8M" safe_mode="" session.save_handler="files"

upload_max_filesize="20M"

Software: Microsoft-IIS/10.0

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36

Server Software: MySQL Community Server (GPL)

Server Version: 5.7.40-log

Server SQL Mode: STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

Parameters: juliano@localhost/dbglpi

Host info: localhost via TCP/IP

PHP version (7.4.33) is supported.

Sessions configuration is OK.

Allocated memory is sufficient.

mysqli extension is installed.

Following extensions are installed: dom, fileinfo, json, simplexml.

curl extension is installed.

gd extension is installed.

intl extension is installed.

libxml extension is installed.

zlib extension is installed.

The constant SODIUM_CRYPTO_AEAD_XCHACHA20POLY1305_IETF_NPUBBYTES is present.

Database engine version (5.7.40) is supported.

No files from previous GLPI version detected.

The log file has been created successfully.

Write access to C:\inetpub\glpi/files/_cache has been validated.

Write access to C:\inetpub\glpi/config has been validated.

Write access to C:\inetpub\glpi/files/_cron has been validated.

Write access to C:\inetpub\glpi/files has been validated.

Write access to C:\inetpub\glpi/files/_dumps has been validated.

Write access to C:\inetpub\glpi/files/_graphs has been validated.

Write access to C:\inetpub\glpi/files/_lock has been validated.

Write access to C:\inetpub\glpi/files/_pictures has been validated.

Write access to C:\inetpub\glpi/files/_plugins has been validated.

Write access to C:\inetpub\glpi/files/_rss has been validated.

Write access to C:\inetpub\glpi/files/_sessions has been validated.

Write access to C:\inetpub\glpi/files/_tmp has been validated.

Write access to C:\inetpub\glpi/files/_uploads has been validated.

PHP 7.4 official support has ended. An upgrade to a more recent PHP version is recommended.

Web server root directory configuration is not safe as it permits access to non-public files. See installation documentation for more details.

The following directories should be placed outside "C:\inetpub\glpi":

‣ "C:\inetpub\glpi/files" ("GLPI_VAR_DIR")

‣ "C:\inetpub\glpi\config" ("GLPI_CONFIG_DIR")

You can ignore this suggestion if your web server root directory is "C:\inetpub\glpi\public".

Sessions configuration is secured.

OS and PHP are relying on 64 bits integers.

exif extension is installed.

ldap extension is installed.

openssl extension is installed.

Following extensions are installed: bz2, Phar, zip.

Zend OPcache extension is installed.

Following extensions are installed: ctype, iconv, mbstring, sodium.

Write access to C:\inetpub\glpi/marketplace has been validated.

Timezones seems loaded in database.

GLPI constants

 

GLPI_ROOT: "C:\inetpub\glpi"

GLPI_CONFIG_DIR: "C:\inetpub\glpi/config"

GLPI_VAR_DIR: "C:\inetpub\glpi/files"

GLPI_MARKETPLACE_DIR: "C:\inetpub\glpi/marketplace"

GLPI_USE_CSRF_CHECK: "1"

GLPI_CSRF_EXPIRES: "7200"

GLPI_CSRF_MAX_TOKENS: "100"

GLPI_USE_IDOR_CHECK: "1"

GLPI_IDOR_EXPIRES: "7200"

GLPI_ALLOW_IFRAME_IN_RICH_TEXT: false

GLPI_SERVERSIDE_URL_ALLOWLIST: ["/^(https?|feed):\/\/[^@:]+(\/.*)?$/"]

GLPI_TELEMETRY_URI: "https://telemetry.glpi-project.org"

GLPI_INSTALL_MODE: "TARBALL"

GLPI_NETWORK_MAIL: "glpi@teclib.com"

GLPI_NETWORK_SERVICES: "https://services.glpi-network.com"

GLPI_MARKETPLACE_ALLOW_OVERRIDE: true

GLPI_MARKETPLACE_MANUAL_DOWNLOADS: true

GLPI_USER_AGENT_EXTRA_COMMENTS: ""

GLPI_DISABLE_ONLY_FULL_GROUP_BY_SQL_MODE: "1"

GLPI_AJAX_DASHBOARD: "1"

GLPI_CALDAV_IMPORT_STATE: 0

GLPI_DEMO_MODE: "0"

GLPI_CENTRAL_WARNINGS: "1"

GLPI_DOC_DIR: "C:\inetpub\glpi/files"

GLPI_CACHE_DIR: "C:\inetpub\glpi/files/_cache"

GLPI_CRON_DIR: "C:\inetpub\glpi/files/_cron"

GLPI_DUMP_DIR: "C:\inetpub\glpi/files/_dumps"

GLPI_GRAPH_DIR: "C:\inetpub\glpi/files/_graphs"

GLPI_LOCAL_I18N_DIR: "C:\inetpub\glpi/files/_locales"

GLPI_LOCK_DIR: "C:\inetpub\glpi/files/_lock"

GLPI_LOG_DIR: "C:\inetpub\glpi/files/_log"

GLPI_PICTURE_DIR: "C:\inetpub\glpi/files/_pictures"

GLPI_PLUGIN_DOC_DIR: "C:\inetpub\glpi/files/_plugins"

GLPI_RSS_DIR: "C:\inetpub\glpi/files/_rss"

GLPI_SESSION_DIR: "C:\inetpub\glpi/files/_sessions"

GLPI_TMP_DIR: "C:\inetpub\glpi/files/_tmp"

GLPI_UPLOAD_DIR: "C:\inetpub\glpi/files/_uploads"

GLPI_INVENTORY_DIR: "C:\inetpub\glpi/files/_inventories"

GLPI_NETWORK_REGISTRATION_API_URL: "https://services.glpi-network.com/api/registration/"

GLPI_MARKETPLACE_PLUGINS_API_URI: "https://services.glpi-network.com/api/glpi-plugins/"

GLPI_I18N_DIR: "C:\inetpub\glpi/locales"

GLPI_VERSION: "10.0.7"

GLPI_SCHEMA_VERSION: "10.0.7@5d45269702917a32805e25b678f6779a98b145f6"

GLPI_MARKETPLACE_PRERELEASES: false

GLPI_MIN_PHP: "7.4.0"

GLPI_MAX_PHP: "8.3.0"

GLPI_YEAR: "2023"

Libraries

 

htmlawed/htmlawed version 1.2.9 in (C:\inetpub\glpi\vendor\htmlawed\htmlawed)

phpmailer/phpmailer version 6.8.0 in (C:\inetpub\glpi\vendor\phpmailer\phpmailer\src)

simplepie/simplepie version 1.5.8 in (C:\inetpub\glpi\vendor\simplepie\simplepie\library)

tecnickcom/tcpdf version 6.4.4 in (C:\inetpub\glpi\plugins\pdf\vendor\tecnickcom\tcpdf)

michelf/php-markdown in (C:\inetpub\glpi\vendor\michelf\php-markdown\Michelf)

true/punycode in (C:\inetpub\glpi\vendor\true\punycode\src)

iamcal/lib_autolink in (C:\inetpub\glpi\vendor\iamcal\lib_autolink)

sabre/dav in (C:\inetpub\glpi\vendor\sabre\dav\lib\DAV)

sabre/http in (C:\inetpub\glpi\vendor\sabre\http\lib)

sabre/uri in (C:\inetpub\glpi\vendor\sabre\uri\lib)

sabre/vobject in (C:\inetpub\glpi\vendor\sabre\vobject\lib)

laminas/laminas-i18n in (C:\inetpub\glpi\vendor\laminas\laminas-i18n\src)

laminas/laminas-servicemanager in (C:\inetpub\glpi\vendor\laminas\laminas-servicemanager\src)

monolog/monolog in (C:\inetpub\glpi\vendor\monolog\monolog\src\Monolog)

sebastian/diff in (C:\inetpub\glpi\vendor\sebastian\diff\src)

donatj/phpuseragentparser in (C:\inetpub\glpi\vendor\donatj\phpuseragentparser\src\UserAgent)

elvanto/litemoji in (C:\inetpub\glpi\vendor\elvanto\litemoji\src)

symfony/console in (C:\inetpub\glpi\vendor\symfony\console)

scssphp/scssphp in (C:\inetpub\glpi\vendor\scssphp\scssphp\src)

laminas/laminas-mail in (C:\inetpub\glpi\vendor\laminas\laminas-mail\src\Protocol)

laminas/laminas-mime in (C:\inetpub\glpi\vendor\laminas\laminas-mime\src)

rlanvin/php-rrule in (C:\inetpub\glpi\vendor\rlanvin\php-rrule\src)

blueimp/jquery-file-upload in (C:\inetpub\glpi\vendor\blueimp\jquery-file-upload\server\php)

ramsey/uuid in (C:\inetpub\glpi\vendor\ramsey\uuid\src)

psr/log in (C:\inetpub\glpi\vendor\psr\log\Psr\Log)

psr/simple-cache in (C:\inetpub\glpi\vendor\psr\simple-cache\src)

psr/cache in (C:\inetpub\glpi\vendor\psr\cache\src)

league/csv in (C:\inetpub\glpi\vendor\league\csv\src)

mexitek/phpcolors in (C:\inetpub\glpi\vendor\mexitek\phpcolors\src\Mexitek\PHPColors)

guzzlehttp/guzzle in (C:\inetpub\glpi\vendor\guzzlehttp\guzzle\src)

guzzlehttp/psr7 in (C:\inetpub\glpi\vendor\guzzlehttp\psr7\src)

glpi-project/inventory_format in (C:\inetpub\glpi\vendor\glpi-project\inventory_format\lib\php)

wapmorgan/unified-archive in (C:\inetpub\glpi\vendor\wapmorgan\unified-archive\src)

paragonie/sodium_compat in (C:\inetpub\glpi\vendor\paragonie\sodium_compat\src)

symfony/cache in (C:\inetpub\glpi\vendor\symfony\cache)

html2text/html2text in (C:\inetpub\glpi\vendor\html2text\html2text\src)

symfony/css-selector in (C:\inetpub\glpi\vendor\symfony\css-selector)

symfony/dom-crawler in (C:\inetpub\glpi\vendor\symfony\dom-crawler)

twig/twig in (C:\inetpub\glpi\vendor\twig\twig\src)

twig/string-extra in (C:\inetpub\glpi\vendor\twig\string-extra)

symfony/polyfill-ctype not found

symfony/polyfill-iconv not found

symfony/polyfill-mbstring not found

symfony/polyfill-php80 in (C:\inetpub\glpi\vendor\symfony\polyfill-php80)

symfony/polyfill-php81 in (C:\inetpub\glpi\vendor\symfony\polyfill-php81)

symfony/polyfill-php82 in (C:\inetpub\glpi\vendor\symfony\polyfill-php82)

league/oauth2-client in (C:\inetpub\glpi\vendor\league\oauth2-client\src\Provider)

league/oauth2-google in (C:\inetpub\glpi\vendor\league\oauth2-google\src\Provider)

thenetworg/oauth2-azure in (C:\inetpub\glpi\vendor\thenetworg\oauth2-azure\src\Provider)

LDAP directories

 

Server: '192.168.0.1', Port: '389', BaseDN: 'dc=kappesberg;dc=com;dc=br', Connection filter:

'(&(objectClass=user)(objectCategory=person))', RootDN: 'kappesberg\administrador', Use TLS: none

SQL replicas

 

Not active

Notifications

 

Way of sending emails: SMTP (cpd@mail.kappesberg.com.br)

Plugins list

 

actualtime           Name: ActualTime                     Version: 2.1.0      State: Enabled

Install Method: Marketplace

news                 Name: Alertas                        Version: 1.10.6     State: Enabled

Install Method: Marketplace

behaviors            Name: Comportamental                 Version: 2.7.2      State: Enabled

Install Method: Manual

pdf                  Name: Imprimir em PDF                Version: 3.0.0      State: Enabled

Install Method: Manual

timelineticket       Name: Linha do tempo dos chamados    Version: 10.0+1.1   State: Enabled

Install Method: Manual

mailanalyzer         Name: Mail Analyzer                  Version: 3.0.0      State: Installed / not activated

Install Method: Manual

ocsinventoryng       Name: OCS Inventory NG               Version: 2.0.4      State: Enabled

Install Method: Manual

dashboard            Name: Painel                         Version: 1.0.2      State: Enabled

Install Method: Manual

resources            Name: Recursos humanos               Version: 3.0.4      State: Enabled

Install Method: Manual

reports              Name: Relatórios                     Version: 1.16.0     State: Enabled

Install Method: Manual

Anything else?

No response

[cedric-anne]

Hi,

Last time we talk about this, you had a script that was killing the GLPI cron.php script when it was taking too many time. Have you still this kind of script?

If you have not anymore such kind of script, and if the problem is a PHP timeout, you wuld probably have something related to the PHP timeout in your GLPI logs.

Anyway, IMHO, we should probably try to handle this kind of case by registering a PHP shutdown function (with register_shutdown_function()) that would change the state of the task to "errored" and add a relevant log entry. I am not sure it is possible to do so many operations when PHP already considers it has reached its timeout.

I think we will not have time to work on this part soon, but maybe it could be done in GLPI 10.1.

[eduardomozart]

Hi,

Last time we talk about this, you had a script that was killing the GLPI cron.php script when it was taking too many time. Have you still this kind of script?

If you have not anymore such kind of script, and if the problem is a PHP timeout, you wuld probably have something related to the PHP timeout in your GLPI logs.

Anyway, IMHO, we should probably try to handle this kind of case by registering a PHP shutdown function (with register_shutdown_function()) that would change the state of the task to "errored" and add a relevant log entry. I am not sure it is possible to do so many operations when PHP already considers it has reached its timeout.

I think we will not have time to work on this part soon, but maybe it could be done in GLPI 10.1.

Hello @cedric-anne, thank you for your response! It's great to see you here.
I'd already removed that script and even changed the exec mode of the mailgate task to GLPI, so it should respect PHP timeout as PHP scripts executed by PHP binary (aka. Task Scheduler) directly doesn't have any time limit by default.
I do not have any timeout error at PHP error log, so I suspect that some other task (like queuednotifications) are "locking" the database so mailgate task fails to access it, as can be seen in #7327. There's no problem failing, but mailgate should be able to change to detect that it's execution failed and try again later, as running the task manually at the later time it works as expected, it simply get stuck on "Running" state and do not run anymore while someone run it manually again.
It would be great if error handling of tasks be improved because this kind of issue with mailgate seems recurrent here at the bug track. I'd already faced similar issues into the past with the mailgate task since GLPI 9.4.5.

[SteadEXE]

It happened to me aswell, mail server crashed while mailgate was running, and task got stuck in running state, I had to manually reset the task.
It happened only once, but it happened.

It is configured to run with a cron, and we do not kill process if it get stuck.
It happened last year, so I can't be sure if problem is still here, but it looks the same as what Eduard is reporting.

[cedric-anne]

#14777 may help to catch errors.

[krishi9999]

I am having issue with gpli mailgate which is not running automatically rather i have to do by manually can someone help me to fix it

[krishi9999]

I am having issue with gpli mailgate which is not running automatically rather i have to do by manually can someone help me to fix it

Code of Conduct

• I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• I have searched the existing issues

Version

10.0.7

Bug description

Hello, When the mailgate task is triggered, sometimes it get stuck. Sometimes took a day, a week or month, but it get stuck again eventually. For me, it seems that the mail server is the culprit because it's slow, even when browsing mails through Webmail. But GLPI should be able to handle those laminas library exceptions and close the DB lock as expected, so when running the mailgate task again into the future when the mailserver is available again it should pull the messages instead of getting stuck and not running the mailgate task anymore. We have to go to the Actions page, click on "X" on "Running" task status of mailgate to make it scheduled again.

It doesn't seems that the task is reaching PHP/IIS request limit, and it's running a GLPI task instead of a CLI one, so it should be respecting PHP timeout and unlocking the task even when ended prematurely. I'm not sure, but maybe it's getting locked because it uses the same DB as queuednotifications or because it got stuck itself because laminas library failed? This error already shown into the past and it seems that when queuednotification is running and mailgate task is triggered, it seems more prone to this issue.

I'm facing this kind of issue for at least two years, and I'd have the opportunity to chat with cedric-ane and trasher about this. While talking to them, they'd said that GLPI tasks code doesn't seem to properly handle task execution failures, so the mailgate task get locked/stuck. We're running GLPI on Windows Server now, but I was already able to face this issue on Linux as well.

I do not believe this specific issue is related with attachments (as can be seen on #7327) because no pending mail message has attachments on it's receiver mail account, and when pulling mails manually it pulls the messages as expected.

Relevant log output

cron.log:


2023-05-04 11:16:31 [901@UNIFI]
Interno #1: Executar mailgate
2023-05-04 11:17:01 [901@UNIFI]
An error occurred trying to connect to collector.<br/>cannot read - connection closed?
2023-05-04 11:17:49 [901@UNIFI]
An error occurred trying to connect to collector.<br/>cannot read - connection closed?
2023-05-04 11:18:00 [@UNIFI]
Can't get DB lock

php-errors.log when collecting through mailgate task:

[2023-05-04 11:17:49] glpiphplog.CRITICAL:   *** Uncaught Exception Laminas\Mail\Protocol\Exception\RuntimeException: cannot read - connection closed? in C:\inetpub\glpi\vendor\laminas\laminas-mail\src\Protocol\Imap.php at line 110
  Backtrace :
  ...\laminas\laminas-mail\src\Protocol\Imap.php:125 Laminas\Mail\Protocol\Imap->nextLine()
  ...r\laminas\laminas-mail\src\Protocol\Imap.php:87 Laminas\Mail\Protocol\Imap->assumedNextLine()
  ...r\laminas\laminas-mail\src\Storage\Imap.php:223 Laminas\Mail\Protocol\Imap->connect()
  src\Toolbox.php:2193                               Laminas\Mail\Storage\Imap->__construct()
  src\MailCollector.php:1404                         Toolbox::getMailServerStorageInstance()
  src\MailCollector.php:698                          MailCollector->connect()
  src\MailCollector.php:1894                         MailCollector->collect()
  src\CronTask.php:1018                              MailCollector::cronMailgate()
  front\cron.php:63                                  CronTask::launch()

The error on php-errors.log seems to be slightly different when attempting to collect mails manually through "Receivers page":

[2023-05-04 11:30:30] glpiphplog.CRITICAL:   *** Uncaught Exception Laminas\Mail\Protocol\Exception\RuntimeException: cannot read - connection closed? in C:\inetpub\glpi\vendor\laminas\laminas-mail\src\Protocol\Imap.php at line 110
  Backtrace :
  ...\laminas\laminas-mail\src\Protocol\Imap.php:137 Laminas\Mail\Protocol\Imap->nextLine()
  ...\laminas\laminas-mail\src\Protocol\Imap.php:256 Laminas\Mail\Protocol\Imap->nextTaggedLine()
  ...\laminas\laminas-mail\src\Protocol\Imap.php:279 Laminas\Mail\Protocol\Imap->readLine()
  ...\laminas\laminas-mail\src\Protocol\Imap.php:344 Laminas\Mail\Protocol\Imap->readResponse()
  ...\laminas\laminas-mail\src\Protocol\Imap.php:781 Laminas\Mail\Protocol\Imap->requestAndResponse()
  ...r\laminas\laminas-mail\src\Storage\Imap.php:269 Laminas\Mail\Protocol\Imap->expunge()
  src\MailCollector.php:1863                         Laminas\Mail\Storage\Imap->removeMessage()
  src\MailCollector.php:960                          MailCollector->deleteMails()
  front\mailcollector.form.php:103                   MailCollector->collect()

Page URL

No response

Steps To reproduce

No response

Your GLPI setup information

Instruções de instalação e configuração
Server
GLPI constants
Libraries
LDAP directories
SQL replicas
Notifications
Plugins list

Anything else?

No response

how did you fix the mailgate automatic running problem same i am running on windows

[krishi9999]

Hi,

Last time we talk about this, you had a script that was killing the GLPI cron.php script when it was taking too many time. Have you still this kind of script?

If you have not anymore such kind of script, and if the problem is a PHP timeout, you wuld probably have something related to the PHP timeout in your GLPI logs.

Anyway, IMHO, we should probably try to handle this kind of case by registering a PHP shutdown function (with register_shutdown_function()) that would change the state of the task to "errored" and add a relevant log entry. I am not sure it is possible to do so many operations when PHP already considers it has reached its timeout.

I think we will not have time to work on this part soon, but maybe it could be done in GLPI 10

[alesnav]

Hi there,

I'm facing this same issue in my GLPI instance (v10.0.17). I had a problem regarding Ticketfilter plugin configuration that generated a php exception.

This was the php log trace for that exception, just in any case it can help, but I guess that this issue may be valid for any critical php exception:

[2025-01-21 19:52:03] glpiphplog.WARNING:   *** PHP User Warning (512): TicketFilter: PregMatch failed! please review the Solved pattern /.*?(?<solved>Closed).*/ and correct it in /opt/glpi
/marketplace/ticketfilter/src/TicketHandler.php at line 308
  marketplace/ticketfilter/src/TicketHandler.php:308 trigger_error()
  marketplace/ticketfilter/src/Filter.php:139        GlpiPlugin\Ticketfilter\TicketHandler->processTicket()
  marketplace/ticketfilter/src/Filter.php:68         GlpiPlugin\Ticketfilter\Filter::searchForMatches()
  src/Plugin.php:1713                                GlpiPlugin\Ticketfilter\Filter::preItemAdd()

As you can see, the automatic action hangs in Running since that moment (two days ago - CLI in GMT, GUI in GMT+1 but same time):

I have disabled the Ticketfilter plugin and also the server was rebooted two times, but it does not work either.

Tried workarounds:

• Execute php -cli bin/console glpi:task:unlock --all but the result is Number of tasks unlocked: 0.
• Launch the mailgate task in force mode: php front/cron.php --force mailgate without any output log, and the mails are not read.
• The only thing that does work is to click on the button inside Receiver through the website: "Get email tickets now":

Is it possible to force the same action launched by the button when being in CLI mode? It could be "valid" as a workaround until the mailgate automatic action could be fixed.

Is there any way to manually change the status to stopped? Maybe in the database?

Thanks!

[eduardomozart]

Hello @alesnav,
Please open an issue with Ticketfilter plugin author to him to fix this RegEx and avoid such error.
As this error report, it doesn't underly into a specific crontask, it's an issue that maybe fixed on GLPI 11, since the GLPI team was pretending to change the way on how crontask are handled into this new version. By now, you can create a task on your crontask/windows agent scheduler to run a command on CLI to free up when a task got stuck: php bin/console task:unlock. Please check the GLPI documentation about this CLI command and how to run it.

[alesnav]

Hello @eduardomozart !

I don't have an issue regarding Ticketfilter, as I disabled the plugin.

I am facing an issue with GLPI tasks because unlock command is not unlocking mailgate task. As I said in the last message, I tried to unlock the task without success.

$ php bin/console task:unlock -t MailCollector::mailgate -vvv
Number of tasks unlocked: 0.
Time elapsed: < 1 sec.
Memory usage: 20.0 MiB.

Is there any way to manually change the status to stopped? Maybe in the database?

Thanks!

[alesnav]

Sorry for double-message.

I've tried to fix it from Database and it did work like a charm.

MySQL [glpi]> UPDATE glpi_crontasks SET state = 1 WHERE name='mailgate';
Query OK, 1 row affected (0.044 sec)
Rows matched: 1  Changed: 1  Warnings: 0

Thanks!

[eduardomozart]

Hello @alesnav, now I saw you already tried to run the task:unlock command before. This command should have work since it seems to update the crontask status on DB as you did. By default, it only considers a task as stuck after 30 minutes it's running, but you can customize it by the --delay parameter.
Into the future, you can also run a task in debug mode to try to figure out what's going on: php -d error_reporting=E_ALL -d display_errors=on <GLPI_ROOT>/front/cron.php --force mailgate --debug && echo $? - you can also check the cronlogs at <GLPI_ROOT>/files/_log/cron.log file.
There's also two files you can check at. The file <GLPI_ROOT>/files/_cron/all.lock blocks all actions, while the <GLPI_ROOT>/files/_cron/name.lock file blocks the action name.

[alesnav]

Good point @eduardomozart , I'll try that debug advanced command next time just to be able to fix it without going to the database .

Thanks for your help!