After upgrading to Fedora 42, Postfix is missing alternative /usr/sbin/sendmail -> /usr/bin/sendmail.postfix Some applications have /usr/sbin/sendmail hardcoded (need time to adjust to the /sbin move), so it would be helpful to have both of the following for now: /usr/bin/sendmail -> /usr/bin/sendmail.postfix /usr/sbin/sendmail -> /usr/bin/sendmail.postfix Reproducible: Always
On my upgraded Fedora 42 system, `/usr/bin/sendmail` does not link to /etc/alternatives/mta as expected: ``` # Seems good [root@darwin etc]# ls -l /usr/sbin/sendmail.postfix lrwxrwxrwx 1 root root 23 Apr 15 22:58 /usr/sbin/sendmail.postfix -> ../bin/sendmail.postfix # Seems good [root@darwin etc]# ls -l /usr/bin/sendmail.postfix -rwxr-xr-x 1 root root 35360 Jan 11 19:00 /usr/bin/sendmail.postfix # seems good [root@darwin etc]# ls -l /usr/sbin/sendmail lrwxrwxrwx 1 root root 21 Apr 17 14:42 /usr/sbin/sendmail -> /etc/alternatives/mta # hmm, doesn't exist, wny not? # (other RPMs like backuppc now refer to this location, and therefore fail to start) [root@darwin etc]# ls -l /usr/bin/sendmail ls: cannot access '/usr/bin/sendmail': No such file or directory # alternatives lists /usr/sbin [root@darwin etc]# alternatives --display mta mta - status is auto. link currently points to /usr/sbin/sendmail.postfix /usr/sbin/sendmail.postfix - priority 60 follower mta-pam: /etc/pam.d/smtp.postfix follower mta-mailq: /usr/bin/mailq.postfix follower mta-newaliases: /usr/bin/newaliases.postfix follower mta-rmail: /usr/bin/rmail.postfix follower mta-sendmail: /usr/lib/sendmail.postfix follower mta-mailqman: /usr/share/man/man1/mailq.postfix.1.gz follower mta-newaliasesman: /usr/share/man/man1/newaliases.postfix.1.gz follower mta-aliasesman: /usr/share/man/man5/aliases.postfix.5.gz follower mta-sendmailman: /usr/share/man/man1/sendmail.postfix.1.gz follower mta-smtpman: /usr/share/man/man8/smtp.postfix.8.gz follower mta-smtpdman: /usr/share/man/man8/smtpd.postfix.8.gz /usr/bin/sendmail.postfix - priority 60 follower mta-pam: /etc/pam.d/smtp.postfix follower mta-mailq: /usr/bin/mailq.postfix follower mta-newaliases: /usr/bin/newaliases.postfix follower mta-rmail: /usr/bin/rmail.postfix follower mta-sendmail: /usr/lib/sendmail.postfix follower mta-mailqman: /usr/share/man/man1/mailq.postfix.1.gz follower mta-newaliasesman: /usr/share/man/man1/newaliases.postfix.1.gz follower mta-aliasesman: /usr/share/man/man5/aliases.postfix.5.gz follower mta-sendmailman: /usr/share/man/man1/sendmail.postfix.1.gz follower mta-smtpman: /usr/share/man/man8/smtp.postfix.8.gz follower mta-smtpdman: /usr/share/man/man8/smtpd.postfix.8.gz Current `best' version is /usr/sbin/sendmail.postfix. ``` I've done `dnf reinstall postfix` but that did not help. `rpm -V postfix` does not show any issues or missing files.
Ran into this issue. As part of debugging I installed sendmail (didn't help). I then removed sendmail and it left behind the correct symlinks so that /usr/sbin/sendmail eventually pointed to /usr/bin/sendmail.postfix. Also had to restart the crond service so that cron output would be mailed rather than going to the journal log,
This also affects `/usr/bin/mail` from `s-nail` package: # mail -s test mironov.ivan To: mironov.ivan Subject: test Test ^D ------- (Preliminary) Envelope contains: To: mironov.ivan Subject: test Send this message [yes/no, empty: recompose]? yes s-nail: Cannot start /usr/sbin/sendmail: executable not found (adjust *mta* variable) /root/dead.letter 8/149 s-nail: ... message not sent Can be circumvented by adding `set mta=/usr/bin/sendmail.postfix` line into `/etc/s-nail.rc`. Note that some other services that use /usr/bin/mail to send e-mail notifications are also affected as consequence of this. One example is a `smartd` from `smartmontools`.
I saw the same, and I resolved it with: dnf reinstall postfix systemctl enable postfix The second step was required due to the reinstall resetting the default state. I also changed a line in /etc/postfix/main.cf from sendmail_path = /usr/sbin/sendmail.postfix to sendmail_path = /usr/bin/sendmail.postfix as that is what is now shipping in the config. However, I think either should work.
Nijel Jewell : That did not work for me. For clarity, the issue is not the `sendmail_path` inside `main.cf`, as that already refers to `sendmail.postfix` directly, which is fine. The issue is the alternatives at `/usr/sbin/sendmail` and `/usr/bin/sendmail`. What does `ls -l /usr/bin/sendmail /usr/sbin/sendmail` produce on your system? On mine, `/usr/bin/sendmail` is missing: # ls -l /usr/bin/sendmail /usr/sbin/sendmail ls: cannot access '/usr/bin/sendmail': No such file or directory lrwxrwxrwx 1 root root 21 Apr 17 14:42 /usr/sbin/sendmail -> /etc/alternatives/mta On my system, `/usr/bin/sendmail` is missing, which is the path that other applications on the system reference. For example, BackupPC as one example: The spec file references %{_sbindir}/sendmail: https://src.fedoraproject.org/rpms/BackupPC/blob/rawhide/f/BackupPC.spec#_193 but on Fedora 42 this macro resolves to /usr/bin: https://docs.fedoraproject.org/en-US/packaging-guidelines/RPMMacros/#macros_installation
Ironically, if upgrading and diligently updating conf files using `rpmconf` to update configuration files to match their latest upstream versions, we get bitten by this bug. But if not being diligent, the conf file remains referencing `/usr/sbin/sendmail` which works fine.
>The issue is the alternatives at `/usr/sbin/sendmail` and `/usr/bin/sendmail`. Sure, I understand that. >What does `ls -l /usr/bin/sendmail /usr/sbin/sendmail` produce on your system? # ls -l /usr/bin/sendmail /usr/sbin/sendmail ls: cannot access '/usr/bin/sendmail': No such file or directory lrwxrwxrwx 1 root root 21 Apr 24 21:28 /usr/sbin/sendmail -> /etc/alternatives/mta # ls -l /usr/*bin/*sendmail* -rwxr-xr-x 1 root root 35360 Jan 12 00:00 /usr/bin/sendmail.postfix lrwxrwxrwx 1 root root 21 Apr 24 21:28 /usr/sbin/sendmail -> /etc/alternatives/mta lrwxrwxrwx 1 root root 23 Apr 24 20:31 /usr/sbin/sendmail.postfix -> ../bin/sendmail.postfix Before the reinstall as described above /usr/sbin/sendmail was missing.
So your system has the same problem as mine in that `/usr/bin/sendmail` is missing. Sounds like we're dealing with two separate but possibly related issues.
This looks like this package has not been converted properly to the /usr/sbin /usr/bin merge. If the /usr/sbin has already been converted to a symlink, you might get an install conflict because the package defines both /usr/bin/sendmail.postfix and /usr/bin/sendmail.postfix and one of theme is a symlink. Also, the alternatives definition gets confusing, so the scripts might need to remove the old alternatives before installing the new one. I have not tested this for postfix, but ran into this issue in another package.
See also these forum posts of more users having issues (and confusion) related to Postfix /usr/bin/sendmail on Fedora 42: https://forums.fedoraforum.org/showthread.php?334152-F42-usr-bin-mail-not-sending-mail-postfix-no-longer-provides-usr-sbin-sendmail. @zbyszek.pl as the owner of https://fedoraproject.org/wiki/Releases/42/ChangeSet#Unify_/usr/bin_and_/usr/sbin it might be helpful if you could provide some guidance as to where the issue(s) may lie with the Postfix package and /usr/bin/sendmail and /usr/sbin/sendmail. Thank you!
(In reply to Villy Kruse from comment #9) > This looks like this package has not been converted properly > to the /usr/sbin /usr/bin merge. > > If the /usr/sbin has already > been converted to a symlink, you might get an install conflict > because the package defines both /usr/bin/sendmail.postfix and > /usr/bin/sendmail.postfix and one of theme is a symlink. Delete the above comments. Looking at the wrong thing. > Also, the alternatives definition gets confusing, so the scripts > might need to remove the old alternatives before installing the > new one. I have not tested this for postfix, but ran into this > issue in another package. The alternatives are hard to test properly, so that may still apply.
I think maybe the same change needs to be made here: https://src.fedoraproject.org/rpms/postfix/blob/rawhide/f/postfix.spec#_546 as was made here: https://src.fedoraproject.org/fork/zbyszek/rpms/sendmail/c/1303dd48316b01051637fb1a9a2e0dca44e8c849
I just remembered a similar issue with cups-client. Here are the scripts preinstall scriptlet (using /bin/sh): # remove alternatives workaround once C11S is released # only run on upgrade (not fresh install) if [ $1 -gt 1 ] ; then /usr/bin/alternatives --remove-follower print /usr/bin/lpr.cups print-lpc || : fi postinstall scriptlet (using /bin/sh): /usr/bin/alternatives --install /usr/bin/lpr print /usr/bin/lpr.cups 40 \ --follower /usr/bin/lp print-lp /usr/bin/lp.cups \ --follower /usr/bin/lpq print-lpq /usr/bin/lpq.cups \ --follower /usr/bin/lprm print-lprm /usr/bin/lprm.cups \ --follower /usr/bin/lpstat print-lpstat /usr/bin/lpstat.cups \ --follower /usr/bin/cancel print-cancel /usr/bin/cancel.cups \ --follower /usr/bin/lpc print-lpc /usr/bin/lpc.cups \ --follower /usr/share/man/man1/cancel.1.gz print-cancelman /usr/share/man/man1/cancel-cups.1.gz \ --follower /usr/share/man/man1/lp.1.gz print-lpman /usr/share/man/man1/lp-cups.1.gz \ --follower /usr/share/man/man8/lpc.8.gz print-lpcman /usr/share/man/man8/lpc-cups.8.gz \ --follower /usr/share/man/man1/lpq.1.gz print-lpqman /usr/share/man/man1/lpq-cups.1.gz \ --follower /usr/share/man/man1/lpr.1.gz print-lprman /usr/share/man/man1/lpr-cups.1.gz \ --follower /usr/share/man/man1/lprm.1.gz print-lprmman /usr/share/man/man1/lprm-cups.1.gz \ --follower /usr/share/man/man1/lpstat.1.gz print-lpstatman /usr/share/man/man1/lpstat-cups.1.gz || : preuninstall scriptlet (using /bin/sh): if [ $1 -eq 0 ] ; then /usr/sbin/alternatives --remove print /usr/bin/lpr.cups || : fi Here the conflicting symbolic link for the lpc command is removed before creating the new symbolic links the alternatives. The lpc command was moved from /usr/sbin to /usr/bin, and the alternatives --install would fail for the lpc command if the symbolic link wasn't removed first.
Is an updated postfix package going to be created to fix this problem for the many many people in the wild that will have this problem? It would not be good to expected that everyone who has this problem is going to be able to find this ticket to apply whatever workarounds are being recommended to fix this problem.
https://src.fedoraproject.org/rpms/postfix/pull-request/13 https://src.fedoraproject.org/rpms/postfix/pull-request/14 seem to resolve the issue.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #15) > https://src.fedoraproject.org/rpms/postfix/pull-request/13 > https://src.fedoraproject.org/rpms/postfix/pull-request/14 > seem to resolve the issue. Consider replacing --slave by --follower. Some people consider the former term "politically incorrect". And, if you could, also fix the other sendmail providers esmtp, exim, msmtp, opensmtpd, postfix, sendmail, and ssmtp.
> Consider replacing --slave by --follower. I added patches to the pull requests. > also fix the other sendmail providers > esmtp, exim, msmtp, opensmtpd, postfix, sendmail, and ssmtp. Yes, that's the plan.
https://src.fedoraproject.org/rpms/exim/pull-request/21 https://src.fedoraproject.org/rpms/esmtp/pull-request/3 https://src.fedoraproject.org/rpms/msmtp/pull-request/7 https://src.fedoraproject.org/rpms/opensmtpd/pull-request/4 https://src.fedoraproject.org/rpms/ssmtp/pull-request/3 https://src.fedoraproject.org/rpms/sendmail/pull-request/13
It looks like the latest update of the alternative program has fixed it for postfix /usr/sbin/sendmail and /usr/bin/sendmail are symbolic links to /etc/alternatives/mta. It probably won't work if you change the alternative to another mta. Now my last issue in /usr/sbin are the iptable-nft entries, which was fixed but the fix was reverted. If I move those entries from /usr/sbin to /usr/bin and reinstal the filesystem package, the sbin to bin merge are now complete.
(In reply to Villy Kruse from comment #19) > It looks like the latest update of the alternative program has fixed it for > postfix > > /usr/sbin/sendmail and /usr/bin/sendmail are symbolic links to > /etc/alternatives/mta. Not for me. # rpm -qa | grep alternatives alternatives-1.33-1.fc42.x86_64 # alternatives --auto mta # alternatives --display mta mta - status is auto. link currently points to /usr/sbin/sendmail.postfix /usr/sbin/sendmail.postfix - priority 60 follower mta-pam: /etc/pam.d/smtp.postfix follower mta-mailq: /usr/bin/mailq.postfix follower mta-newaliases: /usr/bin/newaliases.postfix follower mta-rmail: /usr/bin/rmail.postfix follower mta-sendmail: /usr/lib/sendmail.postfix follower mta-mailqman: /usr/share/man/man1/mailq.postfix.1.gz follower mta-newaliasesman: /usr/share/man/man1/newaliases.postfix.1.gz follower mta-aliasesman: /usr/share/man/man5/aliases.postfix.5.gz follower mta-sendmailman: /usr/share/man/man1/sendmail.postfix.1.gz follower mta-smtpman: /usr/share/man/man8/smtp.postfix.8.gz follower mta-smtpdman: /usr/share/man/man8/smtpd.postfix.8.gz /usr/bin/sendmail.postfix - priority 60 follower mta-pam: /etc/pam.d/smtp.postfix follower mta-mailq: /usr/bin/mailq.postfix follower mta-newaliases: /usr/bin/newaliases.postfix follower mta-rmail: /usr/bin/rmail.postfix follower mta-sendmail: /usr/lib/sendmail.postfix follower mta-mailqman: /usr/share/man/man1/mailq.postfix.1.gz follower mta-newaliasesman: /usr/share/man/man1/newaliases.postfix.1.gz follower mta-aliasesman: /usr/share/man/man5/aliases.postfix.5.gz follower mta-sendmailman: /usr/share/man/man1/sendmail.postfix.1.gz follower mta-smtpman: /usr/share/man/man8/smtp.postfix.8.gz follower mta-smtpdman: /usr/share/man/man8/smtpd.postfix.8.gz Current `best' version is /usr/sbin/sendmail.postfix. # ls -al /usr/bin/sendmail* /usr/sbin/sendmail* -rwxr-xr-x 1 root root 35360 Jan 11 19:00 /usr/bin/sendmail.postfix lrwxrwxrwx 1 root root 21 Apr 17 14:42 /usr/sbin/sendmail -> /etc/alternatives/mta lrwxrwxrwx 1 root root 23 Apr 15 22:58 /usr/sbin/sendmail.postfix -> ../bin/sendmail.postfix As you can see, /usr/bin/sendmail is still missing, which should now be the canonical location of the program.
The two pull requests for postfix are still pending. Please wait until the update is created.
(In reply to Raman Gupta from comment #20) > (In reply to Villy Kruse from comment #19) > > It looks like the latest update of the alternative program has fixed it for > > postfix > > > > /usr/sbin/sendmail and /usr/bin/sendmail are symbolic links to > > /etc/alternatives/mta. > > Not for me. > It doesn't fix it for systems that has already been upgraded to f42.
The two pull requests linked above create the symlink on upgrades. Why wouldn't this work for systems that were previously upgraded?
(In reply to Zbigniew Jędrzejewski-Szmek from comment #23) > The two pull requests linked above create the symlink on upgrades. Why > wouldn't this work for systems that were previously upgraded? Only testing will tell. And the change is not yet available for testing for us. I do believe that it would probably work. However, when switching between mta with the alternatives command, it may still fail as the symlink was only created by the update procedure and not when selecting a different alternative. Most people would not do that so that would be minor problem. I was thinking that the filesystem package could just move the remaining programs from /usr/sbin to /usr/bin and then change /usr/sbin to be a symlink to /usr/bin.
> Only testing will tell. And the change is not yet available for testing for us. > I do believe that it would probably work. Without an additional explanation like this, when you make a comment "this will not work", it's not clear what "this" you have in mind? The state before the last changes or after the last changes. So when you make a comment like this, you kick of a pointless discussion to clarify this. > I was thinking that the filesystem package could just move the remaining programs > from /usr/sbin to /usr/bin and then change /usr/sbin to be a symlink to /usr/bin. Yes, this is what is being done. This package is one of the few remaining that need to be updated before that is complete.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #25) > > Only testing will tell. And the change is not yet available for testing for us. > > I do believe that it would probably work. > > Without an additional explanation like this, when you make a comment "this > will not work", it's not clear what "this" you have in mind? The state before > the last changes or after the last changes. So when you make a comment like > this, you kick of a pointless discussion to clarify this. > Sorry, "this" referred to the quoted text "Not for me".
FEDORA-2025-de53d11dae (postfix-3.10.2-2.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-de53d11dae
FEDORA-2025-7e0015eb32 (postfix-3.9.1-5.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-7e0015eb32
FEDORA-2025-7e0015eb32 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-7e0015eb32` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-7e0015eb32 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Fedora Update System from comment #29) > FEDORA-2025-7e0015eb32 has been pushed to the Fedora 42 testing repository. > Soon you'll be able to install the update with the following command: > `sudo dnf upgrade --enablerepo=updates-testing --refresh > --advisory=FEDORA-2025-7e0015eb32` > You can provide feedback for this update here: > https://bodhi.fedoraproject.org/updates/FEDORA-2025-7e0015eb32 > > See also https://fedoraproject.org/wiki/QA:Updates_Testing for more > information on how to test updates. The updates looks very good. And so does the updates for exim and sendmail.
FEDORA-2025-7e0015eb32 (postfix-3.9.1-5.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
I've installed the specified update package, and I can use mailx/ns-mail to send myself msgs. However, CRON jobs are still not being delivered. Is that a different issue?
Ah, I may not have rebooted, yet. Sorry.
Sorry, restarted cron and it works. Makes sense.