Differential D53061
sendmail: Restart sendmail service on package upgrade Authored by ivy on Mon, Oct 13, 10:21 AM. Tags None Referenced Files
Details If the sendmail package is removed and reinstalled, which currently Work around this by using a trigger to restart sendmail after upgrading MFC after: 3 days
Diff Detail
Event TimelineComment Actions Is it possible that there are still files in mqueue/ ? Would the delete/re-create lead to lost mail ? Comment Actions 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. Comment Actions 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.
Comment Actions
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. Comment Actions 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. 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.
Comment Actions 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. Comment Actions 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. Comment Actions 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.) Comment Actions 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:
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. | ||||||||||||||||||||||||||||||||||||||||||||