[SOLVED] MailAccountFetch Daemon Not Working

[sujeeva]

Hi Friends,

Mail account fetch was running well until last week in my OTRS5 on CentOS. Now mail account fetch is not triggering so automatic ticket creation and followups not working. Below are my configurations:

Daemon::SchedulerCronTaskManager::Task###MailAccountFetch

Schedule - */5 * * * *

# check OTRS daemon status
*/5 * * * * $HOME/bin/otrs.Daemon.pl start >> /dev/null

Cannot find any issue in OTRS log file which is debug enabled. Can you give me a clue to solve this issue?

[wurzel]

Hi,

what did you change on your environment?

Florian

[sujeeva]

Hi Florian,

As of my memory, I didn't do any config change. However, it seems something happened. Is there any file I should check for usage full etc? Main problem is I cannot see any related issue in otrs.log file. Any help much appreciated

[sujeeva]

Just to emphasise that manual fetch works fine. Only the daemon is not working. Daemon is running but not fetching emails from configured emails

[root]

What is the output of otrs.console.pl Maint::Daemon::Summary?

[wurzel]

Hi,

it might be that your $OTRSHOME is wrong. Can you check this? I sometimes have troubles with creating a /home/otrs directory instead of /opt/otrs

So you could try the full path instead of $HOME
*/5 * * * * $HOME/bin/otrs.Daemon.pl start >> /dev/null



regards
Florian

[sujeeva]

Hi root,

Thanks for the command. Below is the output:

Gathering all daemons summary...

Tasks to be executed in future:
There are currently no tasks to be executed in future

Recurrent cron tasks:
NAME LAST EXECUTION LAST STATUS LAST DURATION NEXT EXECUTION
CoreCacheCleanup 2017-02-12 00:20:00 Success 3.0 Second(s) 2017-02-19 00:20:00
EscalationCheck 2017-02-13 05:20:00 Success 1.0 Second(s) 2017-02-13 05:40:00
GenerateDashboardStats 2017-02-13 05:05:00 Success < 1 Second 2017-02-13 06:05:00
ITSMChangesCheck 2017-02-13 05:20:00 Success < 1 Second 2017-02-13 05:30:00
LoaderCacheDelete 2017-02-12 00:30:00 Success < 1 Second 2017-02-19 00:30:00
OTRSBusinessAvailabilityCheck 2017-02-13 05:15:00 Success < 1 Second 2017-02-13 05:35:00
OTRSBusinessEntitlementCheck 2017-02-13 04:45:00 Success < 1 Second 2017-02-13 05:25:00
RegistrationUpdateSend 2017-02-13 04:30:00 Success < 1 Second 2017-02-13 05:30:00
SessionDeleteExpired 2017-02-13 04:55:00 Success < 1 Second 2017-02-13 06:55:00
SpoolMailsReprocess 2017-02-13 00:10:00 Success < 1 Second 2017-02-14 00:10:00
SupportDataCollectAsynchronous 2017-02-13 05:01:00 Success < 1 Second 2017-02-13 06:01:00
TicketAcceleratorRebuild 2017-02-13 01:01:00 Success < 1 Second 2017-02-14 01:01:00
TicketPendingCheck 2017-02-13 04:45:00 Success < 1 Second 2017-02-13 06:45:00
TicketUnlockTimeout 2017-02-13 04:35:00 Success < 1 Second 2017-02-13 05:35:00
MailAccountFetch 2017-02-07 16:10:00 Success 1.0 Second(s) 2017-02-13 05:25:00

Recurrent generic agent tasks:
There are currently no generic agent recurring tasks configured

Unhandled Worker Tasks:
There are currently no tasks waiting to be executed

Handled Worker Tasks:
NAME TYPE NID PID DURATION
MailAccountFetch Cron 001 00013254 5.5 Day(s)

Done.


So it seems MailAccountFetch is running properly. However, I still cannot figure out why automatic email fetching is not working while manual fetch works fine.

[sujeeva]

Hi root,

My previous statement was wrong.

According to the output of otrs.console.pl Maint::Daemon::Summary, MailAccountFetch is not running from 07/02/2017. Can you help me to find the cause for this?

[root]

The job is still running (for 5.5 days). Usually this is the result of a network problem, the job does not recognize this properly.
Kill the process with the pid given in the summary.

[sujeeva]

The job is still running (for 5.5 days). Usually this is the result of a network problem, the job does not recognize this properly.
Kill the process with the pid given in the summary.

Hi Roy,

I stopped services, restarted the server and started services. Still my problem exists.

About your statement about network problem, Can this be a firewall rule change effect? Our security admins sometimes do changes without proper evaluation.

However, even if firewall rule change issue, howcome manual fetch works properly. Any idea please.

[root]

About your statement about network problem, Can this be a firewall rule change effect? Our security admins sometimes do changes without proper evaluation.

From my point of experience: yes. When a sth happens after a successful IMAP/POP3 connect until the jobs finish this could be the result of it. In detail analysis could take hours.

[sujeeva]

The job is still running (for 5.5 days)

Hi Roy,

Thank you very much for the help. Problem solved.

I will explain the problem so that it will be helpful for others in future. MailAccountFetch task scheduled to run in every 3 minutes. This job began to take hours to complete preventing subsequent schedule invokes. The reason was one email account has got hundreds of emails.

Resolution:
I have temporarily disabled problematic email account. Then the other email accounts fetched emails and now the job runs properly in every 3 minutes.

Please make this thread as solved

[root]

Please make this thread as solved

This can be done by you.

To prevent this in the future: switch from fetching e-mails via IMAP/POP3 to receiving via SMTP/procmail