NỘI DUNG
Hôm nay tôi gặp một case khá là lạ. Khách của tôi sử dụng Email Server Zimbra và set dung lượng cho tên miền, khi sử dụng vượt quá và khách tôi đã xoá bớt mail nhưng gửi vẫn không được. Sau khi xoá xong, khách tôi đã chờ 2-4h vẫn không gửi được và báo lỗi An unknown error (mail.DOMAIN_QUOTA_EXCEEDED) has occurred như ảnh đính kèm bên dưới.
Sau khi tìm hiểu, tôi đã xác định được nguyên nhân và cách xử lý. Mời bạn xem hết hướng dẫn này để hiểu và xử lý cho đúng, tránh mất thời gian đoán mò như tôi lúc đầu.
Triệu chứng
- Zimbra được set Domain Aggregate Quota (giới hạn tổng dung lượng cho toàn bộ tên miền), ví dụ 3GB.
- Khách hàng sử dụng vượt mức, gửi mail báo lỗi
mail.DOMAIN_QUOTA_EXCEEDED. - Khách đã xoá bớt mail để giảm dung lượng.
- Trên giao diện kiểm tra (webmail, Admin Console), dung lượng đã giảm rõ ràng, thậm chí xuống thấp hơn nhiều so với hạn mức.
- Nhưng đợi 2-4 tiếng, thậm chí lâu hơn, gửi mail vẫn báo lỗi y hệt như cũ.
Ban đầu tôi nghĩ đơn giản là hệ thống cần thời gian để cập nhật lại số liệu, nên khuyên khách chờ thêm. Nhưng chờ mãi vẫn không hết lỗi, nên tôi quyết định đào sâu vào cơ chế bên trong.
Nguyên nhân
Vấn đề nằm ở chỗ: Zimbra không kiểm tra dung lượng thực tế tại thời điểm gửi mail. Việc chặn gửi mail khi vượt domain quota dựa vào một giá trị đã được tính toán sẵn và lưu trong LDAP, gọi là zimbraAggregateQuotaLastUsage.
Giá trị này chỉ được cập nhật bởi một cron job chạy đúng 1 lần mỗi ngày, thông qua script:
/opt/zimbra/libexec/zmcomputequotausage
Kiểm tra lịch chạy bằng lệnh:
crontab -l -u zimbra | grep -i quota
Tức là mỗi ngày, đúng 2:15 sáng, Zimbra mới quét lại toàn bộ dung lượng thực tế của các mailbox trong domain và ghi số liệu mới vào LDAP. Nếu khách xoá mail vào ban ngày hoặc buổi tối, thì dù có chờ 2-4 tiếng hay cả buổi, hệ thống vẫn dùng số liệu cũ của lần quét trước để chặn gửi mail — vì job tính lại chưa tới phiên chạy tiếp theo.
Đây cũng là lý do dẫn đến sự “vênh” khó hiểu giữa hai nơi:
- Giao diện quản trị / webmail: hiển thị dung lượng tính trực tiếp theo mailbox, gần như real-time.
- Cơ chế chặn gửi mail theo domain quota: dựa vào giá trị cache đã lưu từ lần chạy cron gần nhất, không phải số liệu hiện tại.
Hai nguồn dữ liệu này không đồng bộ với nhau, nên nhìn vào giao diện thấy dung lượng đã giảm, nhưng hệ thống gửi mail vẫn “tưởng” là chưa giảm.
Cách xử lý
Xác nhận lại vấn đề trước khi fix, bằng cách so sánh giá trị cache và dung lượng thực tế:
zmprov -l gd ten-mien.com zimbraDomainAggregateQuota zimbraAggregateQuotaLastUsage
zmprov -l gaa ten-mien.com | while read acc; do zmprov gqu "$(zmhostname)" | grep "$acc"; doneNếu tổng dung lượng thực tế (lệnh thứ 2) đã thấp hơn hạn mức, nhưng zimbraAggregateQuotaLastUsage (lệnh thứ nhất) vẫn cao hơn hạn mức → đúng là do cache chưa được tính lại.
Cách fix: chạy tay script tính quota ngay lập tức, không cần chờ tới phiên cron tiếp theo:
sudo -u zimbra /opt/zimbra/libexec/zmcomputequotausageLưu ý quan trọng: script này chỉ đọc dữ liệu và ghi lại kết quả vào LDAP, không đụng đến mailboxd hay bất kỳ dịch vụ nào đang chạy. Vì vậy hoàn toàn an toàn để chạy trên server production, kể cả server có hàng nghìn tài khoản đang hoạt động, không gây downtime.
Sau khi chạy xong, kiểm tra lại:
zmprov -l gd ten-mien.com zimbraAggregateQuotaLastUsage zimbraDomainAggregateQuotaNếu zimbraAggregateQuotaLastUsage đã thấp hơn hạn mức, gửi thử mail test — lỗi mail.DOMAIN_QUOTA_EXCEEDED biến mất ngay, không cần chờ đợi gì thêm.
Trong case của tôi, sau khi chạy lệnh này, khách gửi mail lại được ngay lập tức.
Cấu hình lại cron
Vì cron mặc định chỉ chạy 1 lần/ngày, nên bất kỳ lúc nào khách xoá mail để giảm dung lượng, họ đều có thể phải chờ tới tối đa 24 tiếng mới thấy hệ thống “nhận ra” là đã giảm — trừ khi admin can thiệp chạy tay như trên.
Để hạn chế tình trạng này lặp lại, có hai hướng xử lý:
1. Tăng tần suất chạy cron
Tăng tần suất chạy cron (khuyến nghị nếu server còn dư tài nguyên), ví dụ chạy mỗi giờ thay vì mỗi ngày:
crontab -e -u zimbraSửa dòng
15 2 * * * /opt/zimbra/libexec/zmcomputequotausage > /dev/null 2>&1Thành
15 * * * * /opt/zimbra/libexec/zmcomputequotausage > /dev/null 2>&1(chạy vào phút 15 của mỗi giờ). Cân nhắc số lượng domain và account trên server trước khi tăng tần suất quá cao, vì script phải quét toàn bộ mailbox mỗi lần chạy.
2. Giữ nguyên lịch, chạy thủ công
Giữ nguyên lịch chạy 1 lần/ngày, nhưng khi có báo lỗi tương tự từ khách hàng, admin chủ động chạy tay:
sudo -u zimbra /opt/zimbra/libexec/zmcomputequotausageKết luận
Lỗi mail.DOMAIN_QUOTA_EXCEEDED không tự hết dù khách đã xoá mail và chờ nhiều giờ, không phải vì hệ thống “chậm cập nhật” một cách mơ hồ, mà vì domain quota trên Zimbra được tính theo cơ chế cache, cập nhật 1 lần/ngày qua cron job, chứ không phải real-time.
Khi gặp tình huống tương tự, thay vì khuyên khách hàng tiếp tục chờ, admin nên:
- Kiểm tra chênh lệch giữa
zimbraAggregateQuotaLastUsagevà dung lượng thực tế. - Chạy tay
/opt/zimbra/libexec/zmcomputequotausageđể cập nhật lại ngay. - Cân nhắc tăng tần suất cron nếu domain của khách thường xuyên sát ngưỡng quota.
Hy vọng bài viết giúp bạn tiết kiệm được thời gian nếu chẳng may gặp phải case tương tự.
Với kinh nghiệm thực chiến từ việc tiếp xúc hàng ngày với vô vàn vấn đề về Website, Hosting, VPS, Server tại Phòng Kỹ thuật AZDIGI, mình luôn ấp ủ niềm đam mê chia sẻ kiến thức.
Mình xây dựng các blog không chỉ để tự trau dồi kỹ năng mà còn để cung cấp những tài liệu, hướng dẫn hữu ích nhất đến cộng đồng. Rất mong nhận được sự quan tâm của các bạn!
Để lại thông tin, mình sẽ phản hồi ngay.