On 03/06/12 14:10, Wietse Venema wrote: > Eray Aslan: >> On Tue, Mar 06, 2012 at 11:48:35AM -0500, Wietse Venema wrote: >>> I think that making everyone wait would be another example of >>> well-meaning people doing things that give Postfix a bad reputation. >> >> postfix start exits successfully but postfix doesn't work, resulting in a >> WTF moment for the user. I am not sure if this is a recommended way to >> start a daemon. It surprises them - hence the original email. > > According to the original complaint, no error was logged, and the > system claimed that the mail system was running. > > If they had looked in the right logfile, and if they had used the > "postfix status" command, all this WTF would have been unnecessary. > > They also claimed they had to to reboot their system to clear up > the problem. > > All this indicates that they have no clue. Going for the lowest > common denominator is not sufficient moditivation to make changes > that cause everyone else to suffer.
It's not really his fault. This is what the startup message looks like: backup2 ~ # /etc/init.d/postfix start * Starting postfix (/etc/postfix)... [ ok ] If postfix has failed to actually start, you get the same message. Moreover, backup2 ~ # killall -9 /usr/lib64/postfix/master backup2 ~ # /etc/init.d/postfix start * WARNING: postfix has already been started backup2 ~ # /etc/init.d/postfix status * status: started This is not ideal, but I wouldn't say it should necessarily be fixed, either. Right now the problem is easy to understand: half of the time on Gentoo, the startup "OK" is meaningless. Everyone knows this, and figures out how to deal with it quickly: backup2 ~ # /etc/init.d/postfix stop * Stopping postfix (/etc/postfix)... [ !! ] * ERROR: postfix failed to stop backup2 ~ # /etc/init.d/postfix zap * Manually resetting postfix to stopped state backup2 ~ # /etc/init.d/postfix start * Starting postfix (/etc/postfix)... [ ok ] If we try to fix it with magic (e.g. wrapping 'postfix status'), a) We require more developer time b) Some easy failure modes get nicer c) Many tricky failures get worse So the benefit is not clear-cut.
