Has the volume of undelivered mail gone down? Perhaps spamassassin is slowly clearing the queue?
No. The volume of undelivered mail grows up. the only way to avoid it is by making
sudo service postfix restart. When i do this, some mails of the list dissapear. So i have to make it some times to clean this lists. Only a few emails are sent without doing anything to them. It seems a problem of extreme slowness of this service.
How much memory is allocated full time to the VM? Spamassassin is a memory hog on a good day I believe.
This VM has 4 GB of ram. This is what “top” says in the Mail-in-a-box machine.
top - 17:41:01 up 1:05, 1 user, load average: 0,14, 0,12, 0,09 Tasks: 321 total, 1 running, 238 sleeping, 0 stopped, 0 zombie %Cpu(s): 0,1 us, 0,1 sy, 0,0 ni, 99,8 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 4039692 total, 1072976 free, 692480 used, 2274236 buff/cache KiB Swap: 4039676 total, 4039676 free, 0 used. 3048248 avail Mem
You need to go to a spam assassin forum and ask questions there.
I think that there is a really serious problem with MIAB in 18.04 or with the procedure of the migration.
Yesterday i decided to prepare another machine. I took a real machine (not virtualized) with 4 GB of ram. I installed on it ubuntu 18 and put the universe repository. I made the installation of MIAB and restore the backup of all the accounts (about 130 accunts. 350 GB).
20 minutes after the restore of the backup, this is the situation (postqueue -p).
As you can see, there are 308 mails in the queue (now 356). I can see that the queue sometimes process one or two mails, but the speed is really really slow.
This is happen in a new machine, not virtualized, no errors during the installation or the restore of the backup… Anybody must have this problem too with MIAB when you have a big number of accounts. And this problem is only with MIAB in 18.04 (in 14.04 this problem doesn’t happend). In “TOP” the machine is iddle (99-97% iddle)
Did the backup you used come from the original 14.04 install, or the new 18.04 install?
Keep in mind that your use case is very abnormal in comparison with the typical installation of MiaB. MiaB was not designed with this use case in mind although it should be perfectly able to handle it. One last question, was this reinstall on a physical machine, or a VPS?
No. I restored from the 14.04 backup (I would’t restore a backup from a installation that may had problems)
I wouldn’t think so … but some people have been known to do strange things so it is better to ask. My last question was if this newest install is on a VPS somewhere or a local machine? With that amount of storage required, I would suspect a local machine …
The reinstall was in a phisical machine (4 GB ram, 4 cores, 1 TB HDD…). The installation of 18.04 was directly in the HDD of the phisicall machine (not in a virtual machine). I decided not to virtualize this to rule out that the problem was caused by virtualization.
Which ISO? Desktop edition, or server edition?
Server edition. Before starting to install MIAB I have done the following::
sudo add-apt-repository universe
sudo apt-get update
sudo apt-get dist-upgrade
and then I installed MIAB. There was no errors in the installation. Then i restored the backup. Again no errors. then i executed again mailinabox to finish the update.
I am all out of ideas … seemingly all should be well. Perhaps @JoshData may see something in this thread but I am out of ideas.
Would you be willing to open an issue on Github so that the developers can look at this?
Were you able to get any help from the spamassassin people? Because at this point everything seems to be pointing at a spamassassin issue as that is where the bottle neck is.
I do see one thing that I may have overlooked … have you actually upgraded to Ubuntu 18.10? Please check.
From previous posts it seems that there is a problem with Spam assassin on your machine. It doesn’t seem like an OS problem. Unfortunately I don’t think there is anyone on this forum with the expertise to troubleshoot your problem with Spam assassin. At least no one has offered.
No. I have 8.04.2 LTS
root@box:/home/marcosms# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.2 LTS
Did you follow the MiaB instructions exactly? Have you made any changes to any settings on the machine?
ALENTO!!! You saved me!!!
If we were closer, I would give you a kiss in the mouth (well … better not).
You suggested me to put a message in GitHub. Before put the message, I look in the previuos messages to see if anybody had the same problem… and i found this thread.
The title of the thread is this:
lost connection with 127.0.0.1[127.0.0.1] while sending end of data
And I remember that i have a lot of messages of “timed out” very similar (as you can see in my last screenshot). It seems that this can be my problem.
the last post says this:
one workaround is to set
lmtp_destination_recipient_limit = 1in main.cf (postfix)
So i triyed to apply this workaround. And voila!! the queues now are working. Now I have 135 messages in the queue (10 minutes ago i have more than 500).
Ok. This is a workaround, but I think that it’s important to solve this trouble in v0.41.
I notice that now MIAB is using more proccessor power as you can see…
Tasks: 231 total, 1 running, 184 sleeping, 0 stopped, 0 zombie %Cpu(s): 57,6 us, 5,8 sy, 0,0 ni, 34,3 id, 1,7 wa, 0,0 hi, 0,7 si, 0,0 st KiB Mem : 3330420 total, 390152 free, 710288 used, 2229980 buff/cache KiB Swap: 3330044 total, 3320828 free, 9216 used. 2376616 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 30210 spampd 20 0 194828 106700 8028 S 60,7 3,2 0:18.96 spampd 30270 spampd 20 0 191200 103148 8028 S 49,8 3,1 0:16.48 spampd 7523 bind 20 0 323572 57120 9264 S 6,6 1,7 0:43.21 named 11331 root 20 0 1203120 19092 6508 S 3,0 0,6 1:31.30 fail2ban-s+
But now all is working. I hope that the processor consumption will decrease when the queues were proccessed.
Thanks thanks thanks!!!
I appreciate the sentiment, but uhmm … well, let’s not.
I would expect that once the backlog gets cleared your CPU and RAM would decrease. Please post an update later …
One day later… I can say that all is right now. When a mail arrive at the mail server, the use of the proccesor grows at 5/10%. I haven’t got large queues now, so the computer do this proccess and then the use of the processor is 1% again.
I don’t know if the developers of MIAB knows this issue. I’m agree with @alento, that says in a previous post that we don’t have a tipical installation of MIAB and perhaps MIAB is not designed for this use (I suppose there should not be many MIAB machines with 120 email users), but this problem exists and any MIAB user is going to have it. It does not matter if there are 10 users on the server or 500.
If any developer needs me to do some test on my server to detect the problem, please let me know.