Zammad not checking email, but Channel.fetch works

Technical assistance
1

Infos:

  • Used Zammad version: 3.4.0
  • Used Zammad installation source: deb packages via repository
  • Operating system: Ubuntu 18.04

Expected behavior:

  • Emails to helpdesk inbox will be imported to Zammad

Actual behavior:

  • Emails sit in inbox and are not imported, unless I run Channel.fetch from Zammad console, in which case email is fetched without complaint

Email worked previously. I have two inboxes going to two different team. Neither works anymore. Outgoing email still works fine if I reply to existing ticket. But Zammad is not fetching emails. It’s possible this is since we updated to 3.4.

The worker is enabled. Not sure where else to look. Nothing jumps out in the production.log – when I fetch manually from console, I can see the check. Otherwise nothing. The scheduler logs are all 0 length which seems weird?

$ sudo systemctl status zammad-worker-1

 zammad-worker-1.service
   Loaded: loaded (/etc/systemd/system/zammad-worker-1.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2020-07-09 19:50:22 UTC; 4min 55s ago
 Main PID: 4647 (ruby)
    Tasks: 9 (limit: 4915)
   CGroup: /system.slice/zammad-worker-1.service
           └─4647 script/scheduler.rb start -t

Jul 09 19:50:22 zammad systemd[1]: Started zammad-worker-1.service.
2

I saw this: After upgrade No Mails and Delayed::Backend::ActiveRecord::Job id: 66271

from console:

irb(main):001:0> Delayed::Job.count
=> 0
irb(main):002:0> Delayed::Job.first
=> nil
irb(main):003:0> Delayed::Job.last
=> nil

And when I go to Settings -> Monitoring it shows an unhealthy status: my two channels are active but have not fetched in X hours. Going to health check page I get

{“healthy”:false,“message”:" channel is active but not fetched for about 2 hours; channel is active but not fetched for about 2 hours",“issues”:[" channel is active but not fetched for about 2 hours"," channel is active but not fetched for about 2 hours"],“actions”:[],“token”:ʺ}

I do not have a “Restart Services” anywhere that I can find.

3

From another thread, I checked this from rails console

p Scheduler.find_by(name: 'Execute jobs')
#<Scheduler id: 8, name: "Execute jobs", method: "Job.run", period: 300, running: 0, last_run: "2020-07-10 21:30:15", prio: 2, pid: "46941592052720", note: nil, error_message: "", status: "ok", active: true, updated_by_id: 1, created_by_id: 1, created_at: "2020-06-13 17:22:29", updated_at: "2020-07-10 21:30:15">
=> #<Scheduler id: 8, name: "Execute jobs", method: "Job.run", period: 300, running: 0, last_run: "2020-07-10 21:30:15", prio: 2, pid: "46941592052720", note: nil, error_message: "", status: "ok", active: true, updated_by_id: 1, created_by_id: 1, created_at: "2020-06-13 17:22:29", updated_at: "2020-07-10 21:30:15">

Well I do not know how the “last run” date is tomorrow but that is what it is right now. So, anything I can do besides wait until 21:30 UTC tomorrow?

4

That’s rather odd.
Did you by chance fiddle with either the systems time (set it grossly to the future) or play around with the jobs period time?

That’s the only two reasons I can think of for such a cause.

5

It’s running in a VM but there were no issues in other virtual machines or the host that I can detect, and I never saw the time itself shift but of course it is possible.

For future reference is there a way through the Console to update the previously ran time to go back into the past where it belongs?

6

Yes you can force the entry to be more current.
However: The following is everything but tested and might bring other “features” that have not been evaluated by me in anyway. If something gets worse because of the above, please don’t blame me. :slight_smile:

Dangerzone

This doesn’t fix any possible issues in your setup and thus should be your last resort.

zammad run rails r "Scheduler.find_by(name: 'Execute jobs').update(last_run: Time.now-5.minutes)"
7

Thank you - I hope not to need it. I am just getting started learning a little Rails. My experience has all been elsewhere.

8

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.