mail-mta/postfix-3.9.0 creates its lib directory as /usr/lib64/postfix/3.9 instead of /usr/lib64/postfix/3.9.0, but /usr/libexec/postfix/postfix-script still believes that the shlib_directory is /usr/lib64/postfix/3.9.0. Result: Postfix cannot be stopped or started after updating to 3.9.0
Do you have an etc-update waiting maybe? I don't know where the ".0" went, but in a clean install of postfix-3.9.0, the relevant main.cf parameters are, mail_version = 3.9 shlib_directory = /usr/lib/postfix/${mail_version} and both of those are the defaults (postconf -d).
(In reply to Michael Orlitzky from comment #1) > Do you have an etc-update waiting maybe? I don't know where the ".0" went, > but in a clean install of postfix-3.9.0, the relevant main.cf parameters are, > > mail_version = 3.9 > shlib_directory = /usr/lib/postfix/${mail_version} > > and both of those are the defaults (postconf -d). Nothing that I see. There were only the expected cfg-updates.
Hm, what do "postconf" and "postconf -d" show for those two variables? You can run e.g. $ postconf mail_version shlib_directory and $ postconf -d mail_version shlib_directory to find the current and default values, respectively. Somehow your shlib path wound up pointing to the wrong place.
(In reply to Michael Orlitzky from comment #3) > Hm, what do "postconf" and "postconf -d" show for those two variables? You > can run e.g. > > $ postconf mail_version shlib_directory > > and > > $ postconf -d mail_version shlib_directory > > to find the current and default values, respectively. Somehow your shlib > path wound up pointing to the wrong place. epsilon3:root:~:74 # postconf mail_version shlib_directory mail_version = 3.9.0 shlib_directory = /usr/lib64/postfix/3.9.0 epsilon3:root:~:75 # postconf -d mail_version shlib_directory mail_version = 3.9 shlib_directory = /usr/lib64/postfix/${mail_version} I just experimented with *removing* the mail_version and all directives that reference it, and that too resolves the issue. This may be a problem of legacy directives no longer needed...?
(In reply to Phil Stracchino (Unix Ronin) from comment #4) > I just experimented with *removing* the mail_version and all directives that > reference it, and that too resolves the issue. This may be a problem of > legacy directives no longer needed...? In the interest of sanity, I'm also going through my config and commenting all directives that merely restate defaults.
I think it's a combination of the upgrade procedure for main.cf, and the fact that postfix 3.9 accidentally(?) defines $mail_version to be 3.9 instead of 3.9.0. The upgrade left you with a shlib_directory that doesn't match $mail_version, but $mail_version is what's used at install time.
(In reply to Michael Orlitzky from comment #6) > I think it's a combination of the upgrade procedure for main.cf, and the > fact that postfix 3.9 accidentally(?) defines $mail_version to be 3.9 > instead of 3.9.0. The upgrade left you with a shlib_directory that doesn't > match $mail_version, but $mail_version is what's used at install time. This, I think, *combined with* legacy config directives that were necessary once upon a time but are no longer needed I think the takeaway here is "The shlib directory location is not what is expected, but *if this is a problem to you* it probably means you need to clean up main.cf." I've just done a thorough spring-cleaning of main.cf on all four of my machines and all of the weirdnesses disappeared.
(In reply to Phil Stracchino (Unix Ronin) from comment #7) > (In reply to Michael Orlitzky from comment #6) > > I think it's a combination of the upgrade procedure for main.cf, and the > > fact that postfix 3.9 accidentally(?) defines $mail_version to be 3.9 > > instead of 3.9.0. The upgrade left you with a shlib_directory that doesn't > > match $mail_version, but $mail_version is what's used at install time. > > This, I think, *combined with* legacy config directives that were necessary > once upon a time but are no longer needed > > I think the takeaway here is "The shlib directory location is not what is > expected, but *if this is a problem to you* it probably means you need to > clean up main.cf." > > I've just done a thorough spring-cleaning of main.cf on all four of my > machines and all of the weirdnesses disappeared. Footnote: Wietse says the mail_version is an error and SHOULD be 3.9.0
I am inclined to leave things as they currently stand. Let me know if you feel otherwise. Thanks for the quick answers here and in the mailing list Micheal
No problem, I'm fine with leaving it alone if you think that's best. I also deleted these variables from my main.cf a while ago because I was tired of looking at them, but I was reluctant to tell anyone else to do that in case there was a good reason for them.
(In reply to Michael Orlitzky from comment #10) > No problem, I'm fine with leaving it alone if you think that's best. I also > deleted these variables from my main.cf a while ago because I was tired of > looking at them, but I was reluctant to tell anyone else to do that in case > there was a good reason for them. I think I actually agree with the "leave it alone" position here. After learning more about it and its behavior, it seems to only be a problem if you have specific directives in your main.cf that aren't actually needed and probably shouldn't be there at all anyway. I'm not even really sure why those directives are exposed; if you DON'T set them yourself then Postfix just Does The Right Thing, and if you DO, and they're set wrong, then it causes problems. The only actual VALID setting for them is the default that Postfix will use anyway if you don't set them, so better not to set them at all. "Remove all directives from main.cf that set or reference mail_version" is an easy and safe workaround.
closing. thanks for the comments
