Is it possible that there are still files in mqueue/ ? Would the delete/re-create lead to lost mail ?

In D53061#1212288, @pi wrote:

Is it possible that there are still files in mqueue/ ? Would the delete/re-create lead to lost mail ?

i'm fairly sure that if there are files there, it won't be deleted. this is why we don't see this with /var/spool/clientmqueue which contains a PID file while smmsp is running.

so this issue cannot cause mail to be lost, except in the sense that if sendmail can't deliver any mail, that mail will be lost after 5 days when it expires from the queue.

This is a major break with tradition. I'm not opposed to it, but it should receive wider discussion, and we should consider doing the same for other services as well.

If the sendmail package is removed and reinstalled, which currently happens on every upgrade due to pkg(8) split upgrade issues, smmsp will stop working because its open handle to /var/spool/mqueue is no longer valid after pkg removes and recreates this directory.

Unless there is a bug somewhere I'm not aware of, split upgrades should not be a problem on the stable/15 branch after we stop re-arranging and moving files between packages constantly.

I also have plans to get rid of them completely in theory, but that is a long term project that will require significant restructuring in pkg and definitely won't be ready by 15.0.

In D53061#1212412, @ifreund_freebsdfoundation.org wrote:

Unless there is a bug somewhere I'm not aware of, split upgrades should not be a problem on the stable/15 branch after we stop re-arranging and moving files between packages constantly.

even if that's the cause, it doesn't help for stable/15 and main users; for example, this leaves sendmail constantly broken on my development systems, meaning i don't get the periodic(8) mail i rely on. and for 15.0, we can't guarantee that no future updates will cause a split upgrade of sendmail.

In D53061#1212403, @des wrote:

This is a major break with tradition. I'm not opposed to it, but it should receive wider discussion, and we should consider doing the same for other services as well.

i'm not particularly fond of this approach, but the alternative is silently breaking sendmail every time someone upgrades, which seems worse. if anyone has a better suggestion for how to fix that, it would probably be better than this.

I note that the sshd daemon is restarted when it is reinstalled. The sshd daemon is restarted since its update may be security related and thus the security fix should take effect as soon as the updated version is available.

In D53061#1212516, @mckusick wrote:

I note that the sshd daemon is restarted when it is reinstalled. The sshd daemon is restarted since its update may be security related and thus the security fix should take effect as soon as the updated version is available.

The reason why we restart sshd on upgrade is that it execs itself for each new connection and may stop accepting connections if the version of sshd on disk (which gets exec'd) was not built from the same sources as the currently running daemon, so people found themselves locked out of their servers after freebsd-update.

pkgbase doesn't restart sshd on upgrade, but that's something we might want to consider if it causes problems not to do so. (i haven't run into that myself, but that's probably because i run sshd from inetd.)

We should, cf. D35109

On one hand, there is an argument to be made that upgrading the sendmail version should trigger a restart so the new version starts running. However, if that upgrade requires an admin to either adjust or regenerate their configuration, then restarting could be dangerous (especially since the restart will likely trigger a queue run). My preference would to address the root cause -- the mqueue directory being removed when the package is upgraded. IMHO, once created, the queue directory should never be removed, even if the package is deleted. Many ports/pkgs do this instead:

You may need to manually remove /usr/local/etc/pam.d/sudo if it is no longer needed.
You may need to manually remove /usr/local/etc/namedb/named.conf if it is no longer needed.
You may need to manually remove /usr/local/etc/bird.conf if it is no longer needed.
You may need to manually remove /usr/local/etc/ssl/cert.pem if it is no longer needed.

I would prefer to see the mqueue directory left behind on package delete, optionally with a message like the ones above. If that isn't possible, then the next best thing (and admittedly a hack) is for the sendmail rc.d script to force to remain by creating a file in that directory (e.g., /var/spool/mqueue/.keep) to prevent the directory from being removed by the package system. If neither is acceptable, then I guess we'll be forced to restart sendmail each time.

In the mean time, I'll discuss adding an additional chdir() call when the directory disappears underneath the running daemon with the upstream team (that change, if it happens, won't be released in time for 15.0-RELEASE though.

bapt believes the pkg(8) bug causing this issue will be fixed prior to 15.0-RELEASE, so i'm going to hold off on landing this a bit longer in the hope that happens.

/cc @cperciva