Ho to delete queue data

We are conducting an evaluation test of Kumomta internally. Yesterday, we sent 800,000 pieces of email data via SMTP (of course, it was a fake send). We are simulating various scenarios, one of which is how to quickly clear the data in the channel (assuming the SMTP is hacked).
We found the “flush” in the documentation and realized it wasn’t what we wanted. We could only try to use “bounce”.
/opt/kumomta/sbin/kcli bounce --everything --reason ‘PURGING ALL THE QUEUES!’ --suppress-logging
However, after executing it, about an hour later, we restarted Kumomta. I think maybe the “bounce” operation hadn’t been completed at that time? As a result, after the restart, the queues were still sending data outward. The information is as follows: Context: Enumerated, ReadyQueueWasFull. Next due in 33s 999ms 910us 325ns at 2025-03-06T05:50:58.135334573Z

Kcli bounce is the right way to go here

‘ /opt/kumomta/sbin/kcli bounce --everything --reason ‘PURGING ALL THE QUEUES!’ --suppress-logging —duration 3600’
That will administer bounce everything in all queues for 3600seconds.

More info is here

You can force it to happen sooner if you follow the bounce with a rebind:
kcli rebind —everything —always-flush — reason “make bounce happen faster”

"If the queue wasn’t changed, then the next-due time of the message will remain unchanged, unless you specified --always-flush. In that case, the message will be placed back into its original queue but be eligible for immediate delivery. " . if i only want to quick delete all queue message , how should i do?

Actually, I no longer want the data in Kumomta and would like to clear it directly.

So it’s good way is : 1. /opt/kumomta/sbin/kcli bounce --everything --reason ‘PURGING ALL THE QUEUES!’ --suppress-logging 2. /opt/kumomta/sbin/kcli rebind --reason ‘every’ --always-flush --suppress-logging --everything . it to happen sooner

Yes. That is how I would (and have) done it in an emergency.

I’m not sure why. I executed these two commands, but according to the log, there are still data waiting to be sent. The log shows: Enumerated, ReadyQueueWasFull. Next due in 33s 999ms 910us 325ns at 2025-03-06T05:50:58.135334573Z
There are also many retries waiting in the log. Can’t the above two commands bounce all the data?
For example, expired records;

“feedback_report”: null,
“queue”: “default-tenant@yahoo.com”,
@timestamp”: “2025-03-06T14:00:29.753Z”,
“num_attempts”: 6,
“egress_source”: null,
“headers”: {
“http_user_agent”: null,
“content_type”: “application/json”,
“request_path”: “/”,
“request_method”: “POST”,
“http_host”: “127.0.0.1:5000”,
“http_version”: “HTTP/1.1”,
“content_length”: “759”,
“http_accept”: “/
},
“meta”: {},
“sender”: “test@test.com”,
“peer_address”: null,
“timestamp”: 1741269629,
“delivery_protocol”: null,
“response”: {
“command”: null,
“code”: 551,
“enhanced_code”: {
“subject”: 4,
“class”: 5,
“detail”: 7
},
“content”: “Next delivery time would be 1day 12h 23m 28s 46ms 131us 532ns after creation, which exceeds max_age=1day”
},
“source_address”: null,
“type”: “Expiration”,

the timestamp": 1741269629, of couse 2025-03-05 20:16 ; So bounce not Influence this data?

That seems very odd. There must be something else going on. Please share your current configs and I’ll try to take a look today.

Also please share your deployment architecture (CPU,Ram, drive).

Okay, I’m not at my place right now. I’ll provide it when I get back. Thank you.

Ok

Hi Tom . Maybe I have find the problem. I have install two kumomta in one server only for test HA . I copy the kumomaster dir to kumoslave dir .So when i exec /opt/kumomtaslave/sbin/kcli rebind even in salve klic ,it also effect kumomaster’s queue .

So i ./kcli --endpoint http://127.0.0.1:8000 bounce and ./kcli --endpoint http://127.0.0.1:8001 bounce it is work fine.

So may be I want to konw ,How can i install to kumomta in one server without docker .. I use systemctl dnf install .

There is a full tutorial here

and that’s followed by detailed instructions including server setup and install on several different operating systems.