Zammad 6.3.1 on Debian.
Everything was working fine, but then I ran out of space due to the http_logs table filling up (see issue https://community.zammad.org/t/tables-http-logs-and-friends-are-eating-all-my-storage-space/15275/4). I cleaned up the space, make zammad, nginx and postgresql server restarted and everything seems to work, but now the incoming emails are not processed, and remain on the mail server.
What can I search for? Is there a scheduled process that I need to restart?
I’ve also rebooted the whole server, without any success: emails are still in the mailbox and not downloaded by zammad.
The email channels does look good and don’t show errors. Any idea?
I‘m not a pro but try to save the mail settings again. All tests ok there?
If all settings are correct and the connection test is ok, open the production.log and search for any errors. You find it here: /opt/zammad/log
@Dennis1993 thanks for the suggestion. I’ve reapplied all the email settings, and in fact the system notifies me that there are five emails in the inbox, so I guess that zammad is able to connect to the mailbox. The settings have been applied with success. However, nothing has changed.
In the logs I don’t find anything related to email:
$ sudo grep -i error /opt/zammad/log/production.log
E, [2024-08-22T00:44:45.106250#4089507-310296800] ERROR -- : ImportJob 'Import::Ldap' failed: At least one user needs to have admin permissions.
E, [2024-08-22T00:44:45.106280#4089507-310296800] ERROR -- : At least one user needs to have admin permissions. (Exceptions::UnprocessableEntity)
E, [2024-08-22T01:43:52.503181#4089507-332461040] ERROR -- : ImportJob 'Import::Ldap' failed: At least one user needs to have admin permissions.
E, [2024-08-22T01:43:52.503210#4089507-332461040] ERROR -- : At least one user needs to have admin permissions. (Exceptions::UnprocessableEntity)
E, [2024-08-22T02:44:55.602800#4089507-354589860] ERROR -- : ImportJob 'Import::Ldap' failed: At least one user needs to have admin permissions.
E, [2024-08-22T02:44:55.602830#4089507-354589860] ERROR -- : At least one user needs to have admin permissions. (Exceptions::UnprocessableEntity)
E, [2024-08-22T03:44:02.100459#4089507-376753560] ERROR -- : ImportJob 'Import::Ldap' failed: At least one user needs to have admin permissions.
E, [2024-08-22T03:44:02.100505#4089507-376753560] ERROR -- : At least one user needs to have admin permissions. (Exceptions::UnprocessableEntity)
E, [2024-08-22T04:44:58.168781#4089507-398882300] ERROR -- : ImportJob 'Import::Ldap' failed: At least one user needs to have admin permissions.
E, [2024-08-22T04:44:58.168819#4089507-398882300] ERROR -- : At least one user needs to have admin permissions. (Exceptions::UnprocessableEntity)
E, [2024-08-22T05:47:06.152947#4089507-421011020] ERROR -- : ImportJob 'Import::Ldap' failed: At least one user needs to have admin permissions.
E, [2024-08-22T05:47:06.152978#4089507-421011020] ERROR -- : At least one user needs to have admin permissions. (Exceptions::UnprocessableEntity)
E, [2024-08-22T06:45:28.940354#4089507-443176560] ERROR -- : ImportJob 'Import::Ldap' failed: At least one user needs to have admin permissions.
E, [2024-08-22T06:45:28.940411#4089507-443176560] ERROR -- : At least one user needs to have admin permissions. (Exceptions::UnprocessableEntity)
E, [2024-08-22T07:44:36.161771#4089507-465305400] ERROR -- : ImportJob 'Import::Ldap' failed: At least one user needs to have admin permissions.
E, [2024-08-22T07:44:36.161807#4089507-465305400] ERROR -- : At least one user needs to have admin permissions. (Exceptions::UnprocessableEntity)
E, [2024-08-22T08:45:26.602307#4098252-220500] ERROR -- : ImportJob 'Import::Ldap' failed: At least one user needs to have admin permissions.
E, [2024-08-22T08:45:26.602365#4098252-220500] ERROR -- : At least one user needs to have admin permissions. (Exceptions::UnprocessableEntity)
E, [2024-08-22T09:44:33.508664#595-256600] ERROR -- : ImportJob 'Import::Ldap' failed: At least one user needs to have admin permissions.
E, [2024-08-22T09:44:33.508703#595-256600] ERROR -- : At least one user needs to have admin permissions. (Exceptions::UnprocessableEntity)
Since the errors are related to the LDAP integration, I re-validated also that configuration and the system has run again the synchronization.
So far, nothing has changed, and the system is still not download the emails from the inbox.
Just for the records:
Ideas?
You wrote in the other thread you truncated the table. Is the auto_increment resettet?
Maybe here is a problem. But I don’t know.
I know this database design from ILIAS. Here the auto_increment is saved in another table too and now the IDs doesn’t match. Maybe the same problem here 
You know the last ID of the last entry? Then you can test to set this value in the table.
Maybe another technical guy can help here or has an idea. I‘m a user like you and try to help 
Does Zammad fetch emails according to log at all?
INFO -- : fetching would be what you’re looking for.
@MrGeneration apparently it is not fetching: the lines in the logs are related to when I tried to disable/reenable the email configuration (that as I’ve already written, sent/removed the test email):
$ sudo grep fetching /opt/zammad/log/*
/opt/zammad/log/production.log:I, [2024-08-22T10:15:22.103893#586-148900] INFO -- : fetching imap (imap.gmail.com/test.email@foo.it port=993,ssl=true,starttls=false,folder=INBOX,keep_on_server=false,auth_type=LOGIN)
/opt/zammad/log/production.log:I, [2024-08-22T10:15:42.373055#586-149480] INFO -- : fetching imap (imap.gmail.com/test.email@foo.it port=993,ssl=true,starttls=false,folder=INBOX,keep_on_server=false,auth_type=LOGIN)
/opt/zammad/log/production.log:I, [2024-08-22T10:59:55.792517#586-149540] INFO -- : fetching imap (imap.gmail.com/test.email@foo.it port=993,ssl=true,starttls=false,folder=INBOX,keep_on_server=false,auth_type=LOGIN)
/opt/zammad/log/production.log:I, [2024-08-22T11:00:08.766660#586-149400] INFO -- : fetching imap (imap.gmail.com/test.email@foo.it port=993,ssl=true,starttls=false,folder=INBOX,keep_on_server=false,auth_type=LOGIN)
$ date
gio 22 ago 2024, 12:41:17, CEST
on the PostgreSQL side I’ve (if it helps):
zammad=# select area, id, active, last_log_in, last_log_out, status_in, status_out from channels;
area | id | active | last_log_in | last_log_out | status_in | status_out
---------------------+----+--------+-------------+--------------+-----------+------------
Email::Notification | 2 | f | | | | ok
Email::Notification | 1 | t | | | | ok
Email::Account | 3 | t | | | ok | ok
@Dennis1993 the http_logs table is already accumulting stuff again, so I don’t believe it is a problem of resetting the autoincrement. However I could reset the sequence if that make sense (please, someone advice).
What does Scheduler.where(active: false).count return in a rails console?
$ sudo -u zammad zammad run rails c
Loading production environment (Rails 7.0.8.4)
[1] pry(main)> Scheduler.where(active: false).count
=> 2
[2] pry(main)> Scheduler.where(active: true).count
=> 27
and more in details:
[3] pry(main)> Scheduler.where(active: false)
=> [#<Scheduler:0x00007f8d64bfc810
id: 4,
name: "Check channels.",
method: "Channel.fetch",
period: 30,
running: 0,
last_run: Sat, 17 Aug 2024 01:22:28.511000000 UTC +00:00,
prio: 1,
pid: "149160",
note: nil,
error_message: "Failed to run Channel.fetch after 11 tries.",
status: "error",
active: false,
timeplan: {},
updated_by_id: 33,
created_by_id: 1,
created_at: Tue, 30 Jul 2024 07:03:52.031000000 UTC +00:00,
updated_at: Sat, 17 Aug 2024 01:21:34.244000000 UTC +00:00>,
#<Scheduler:0x00007f8d64e63ea0
id: 2,
name: "Process ticket escalations.",
method: "Ticket.process_escalation",
period: 300,
running: 0,
last_run: Sat, 17 Aug 2024 01:22:29.514000000 UTC +00:00,
prio: 1,
pid: "149180",
note: nil,
error_message: "Failed to run Ticket.process_escalation after 11 tries.",
status: "error",
active: false,
timeplan: {},
updated_by_id: 1,
created_by_id: 1,
created_at: Tue, 30 Jul 2024 07:03:52.026000000 UTC +00:00,
updated_at: Sat, 17 Aug 2024 01:21:40.340000000 UTC +00:00>]
Note that Sat, 17 Aug 2024 is probably when the server did run out of disk space hence avodiing zammad to work correctly.
Is this something I should remove in order for the scheduler to restart?
Please stop being so in love with removing stuff. You’d brick the system.
Instead do this…:
Scheduler.where(status: 'error', active: false).update(status:'ok', error_message: nil, active: true);
Then restart Zammad.
It worked, thanks a lot.
By the way, I’m not going to delete anything, I’m trying to understand how Zammad is working internally. Is this scheduling issue/restarting documented somewhere?
Nope. It shouldn’t occur at all usually. I’ve had to use this below 100 times in the last 6 years and basically only on mayor fuck ups system wise.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.