==== REQUIRED BASIC INFO OF YOUR IREDMAIL SERVER ====
- iRedMail version (check /etc/iredmail-release): 1.8.0 maria db
- Deployed with iRedMail Easy or the downloadable installer? downloadable installer
- Linux/BSD distribution name and version: Ubuntu server 20.04->22.04->22.04 (problem after do_release_upgrade 22.04->24.04.
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): mysql
- Web server (Apache or Nginx): nginx
- Manage mail accounts with iRedAdmin-Pro? no pro
- [IMPORTANT] Related original log or error message is required if you're experiencing an issue.
====
(I can't post links, but hopefully my references make sense)

Last Friday, I upgraded from 20.04 to 22.04 successfully following the directions on iredmail forum topic20565-direct-upgrade-ubuntu-2004-to-2204-guide.html

Then, today I upgraded from 22.04 to 24.04 using the instructions: iredmail docs upgrade.ubuntu.22.04-24.04.html

After finishing the release upgrade and rebooting the server on 24.04, and going through the install process again for iredapd, iredadmin and mlmmjm I was unable to send or receive mail but I was also unable to resolve domain names.

I was able to find another instance of this happening on an OpenVZ system where the user does not have the ability to update the kernel (currently running the 5.4.0) and it looked like the only option at this time was to stop using systemd-resolved, due to an issue in systemd-resolved on 24.04 systems running in OpenVZ: the github site /systemd/systemd/issues/34580

#fix dns resolution after update to 24.04 by disabling systemd-resolved
sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved
sudo rm /etc/resolv.conf
sudo nano /etc/resolv.conf

#paste in /etc/resolv.conf
nameserver 8.8.8.8
nameserver 1.1.1.1

Making that change allowed me to resolve DNS and ping google.com.

So back to the mail issue.
There was nothing happening in /var/log/mail.log (because as I found out later, postfix wasn't running).

Running "lsof -i -P -n | grep LISTEN" didn't reveal anything listening on ports 25 or 587, but I could see dovecot on 993/995/143/110.

systemctl status postfix:

postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; preset: enabled)
     Active: active (exited) since Tue 2026-05-05 01:37:36 UTC; 45min ago
       Docs: man:postfix(1)
    Process: 33358 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
   Main PID: 33358 (code=exited, status=0/SUCCESS)

but there was an error message in systemctl status postfix*

 postfix@-.service - Postfix Mail Transport Agent (instance -)
     Loaded: loaded (/usr/lib/systemd/system/postfix@.service; enabled-runtime; preset: enabled)
     Active: failed (Result: exit-code) since Tue 2026-05-05 01:37:36 UTC; 9s ago
       Docs: man:postfix(1)
    Process: 33330 ExecStartPre=/usr/lib/postfix/configure-instance.sh - (code=exited, status=1/FAILURE)

I was able to run:

postfix start

Then I started seeing successful messages in /var/log/mail.log and I could see master
running and listening on 25 and 587. 

postfix check

postfix: Postfix is using backwards-compatible default settings
postfix: See postfixorgwebsite /COMPATIBILITY_README.html for details
postfix: To disable backwards compatibility use "postconf compatibility_level=3.6" and "postfix reload"
postfix/postfix-script: warning: /var/spool/postfix/etc/resolv.conf and /etc/resolv.conf differ
postfix/postfix-script: warning: /var/spool/postfix/lib/x86_64-linux-gnu/libgcc_s.so.1 and /lib/x86_64-linux-gnu/libgcc_s.so.1 differ

I copied my resolv.conf and x86_64-linux-gnu/libgcc_s.so.1 into the postfix CHROOT in the appropriate locations, and then running postfix check stopped giving the two warnings, and only the messages about backwards compatibility.

But after running systemctl stop postfix and systemctl start postfix, I was still seeing the same error message in systemctl status postfix*.

I tried running /usr/lib/postfix/configure-instance.sh manually to see if I could see any error message output and there was no output, but now when I run the command again, it's giving different output:
systemctl status postfix*

Unit postfix-mysql.so.service could not be found.
Unit postfix-pcre.so.service could not be found.
Unit postfix_groups.pl.service could not be found.

tail -200 /etc/postfix/dynamicmaps.cf

# dict-type     so-name (pathname)      dict-function   mkmap-function
pcre    postfix-pcre.so dict_pcre_open
mysql   postfix-mysql.so        dict_mysql_open

postconf -m also still shows mysql and pcre in the list.

So now I have mail sending and receiving working again, but I think something with postfix is still borked and I'm afraid to restart my server.

checking the processes that are listening on 25 and 587 again now, it looks like it has changed and postscree (postscreen?) is listening on 25 and smtpd is listening on 587, which I'm pretty sure is different from what I saw after I first ran "postfix start".

I have a full backup from before the upgrade on 20.04->22.04 that I could restore, or I could backup the databases and vmail and DKIM and do a VM reinstall from scratch and then migration and reinstall and restore when I have more time in a few days, but I was hoping that this was something that I could figure out and kick a full reinstall down the road further.

Thanks for any other ideas or hints you might have,
natec