Postfix fails to start at boot time

Bug #56235 reported by Tony Green
16
Affects Status Importance Assigned to Milestone
postfix (Debian)
Incomplete
Unknown
postfix (Ubuntu)
Invalid
Medium
LaMont Jones

Bug Description

Binary package hint: postfix

When the postfix script in /etc/init.d runs, postfix fails to start and a message "postfix/postfix-script: fatal: usage: postfix start (or stop, reload, abort, flush, check, set-permissions, upgrade-configuration)" is issued.

Changing the line which reads:
"if start-stop-daemon --start --exec ${DAEMON} -- quiet-quick-start; then"

to
"if start-stop-daemon --start --exec ${DAEMON} -- start; then"

remedies the problem.
This is a new installation of Kubuntu 6.06.

Revision history for this message
LaMont Jones (lamont) wrote : Re: [Bug 56235] Postfix fails to start at boot time

On Sun, Aug 13, 2006 at 01:11:45PM -0000, Tony Green wrote:
> Changing the line which reads:
> "if start-stop-daemon --start --exec ${DAEMON} -- quiet-quick-start; then"
> to
> "if start-stop-daemon --start --exec ${DAEMON} -- start; then"
> remedies the problem.
> This is a new installation of Kubuntu 6.06.

This sounds more like an upgrade issue... That or someone broke
/etc/postfix/postfix-script to not support the extra commands...

lamont

Revision history for this message
Tony Green (ubuntu-beermad-deactivatedaccount) wrote :

I suspect the latter. This was my first Ubuntu installation on a freshly-formatted partition, so it won't have been due to something left behind from the old Mandriva installation.

I've also now noticed that the script doesn't shut it down either, for the same reason:
"if ${DAEMON} quiet-stop; then"
needs to read
"if ${DAEMON} stop; then"

Tony

Revision history for this message
LaMont Jones (lamont) wrote : Re: [Bug 56235] Re: Postfix fails to start at boot time

On Sun, Aug 13, 2006 at 02:35:56PM -0000, Tony Green wrote:
> I suspect the latter. This was my first Ubuntu installation on a
> freshly-formatted partition, so it won't have been due to something left
> behind from the old Mandriva installation.

Please send me a copy of /etc/postfix/postfix-script (or it attach to the bug)

thanks,
lamont

Changed in postfix:
status: Unconfirmed → Needs Info
Revision history for this message
iso (iso-wemba) wrote :

Just installed Ubuntu 7.04 from scratch and the bug is still there! The /etc/init.d/postfix script needs to be changed.

Adding "start" as shown below works for me:

 if start-stop-daemon --start --exec ${DAEMON} start -- quiet-quick-start; then

Revision history for this message
Scott Kitterman (kitterman) wrote :

I'm not seeing this with a current (upgraded from Dapper, upgraded from Edgy) server. /etc/init.d/postfix stop start and reload all work for me.

Revision history for this message
iso (iso-wemba) wrote :

This is strange, because the script installed with Ubuntu 7.04 calls /usr/sbin/postfix with the wrong syntax.
The commands "start" and "stop" have to be used with /usr/sbin/postfix, but they are not. Maybe the script
/etc/init.d/postfix in your system comes from an old distribution, when it was still correct? I installed my system from scratch.

Please check lines 74 and 86 of the script. Do they read
    ... ${DAEMON} start ...
and
    ... ${DAEMON} stop ...
respectively?

Revision history for this message
Scott Kitterman (kitterman) wrote :

Line 74:

            if start-stop-daemon --start --exec ${DAEMON} -- quiet-quick-start; then

Line 86:

            if ${DAEMON} quiet-stop; then

Revision history for this message
iso (iso-wemba) wrote :

On my system, when the script is like yours, I get the following error message:

$ sudo /etc/init.d/postfix stop
 * Stopping Postfix Mail Transport Agent postfix
postfix/postfix-script: fatal: usage: postfix start (or stop, reload, abort, flush, check, set-permissions, upgrade-configuration)

Similarly for "/etc/init.d/postfix start"

I think this error message is indeed correct, since /usr/sbin/postfix (the value of the variable DAEMON)
does require a command like "stop" or "start". I don't understand how the script can call it like it does
and not generate an error.

Perhaps you could try to run the /usr/sbin/postfix program directly, like this:
$ sudo /usr/sbin/postfix -- quiet-quick-start

On my system this generates an error:

postfix/postfix-script: fatal: usage: postfix start (or stop, reload, abort, flush, check, set-permissions, upgrade-configuration)

Similarly for stop:

$ sudo /usr/sbin/postfix quiet-stop
postfix/postfix-script: fatal: usage: postfix start (or stop, reload, abort, flush, check, set-permissions, upgrade-configuration)

Revision history for this message
Scott Kitterman (kitterman) wrote :

/usr/sbin/postfix -- quiet-quick-start runs without error on my system. One difference is that I've enabled the root account on my servers so I'm doing:

# /usr/sbin/postfix -- quiet-quick-start

not

$ sudo /usr/sbin/postfix -- quiet-quick-start

I wonder if this is somehow related to Ubuntu's configuration of sudo.

If you do

$ sudo su
# /usr/sbin/postfix -- quiet-quick-start

Is it any different?

Revision history for this message
iso (iso-wemba) wrote :

No, it is not different:

# /usr/sbin/postfix -- quiet-quick-start
postfix/postfix-script: fatal: usage: postfix start (or stop, reload, abort, flush, check, set-permissions, upgrade-configuration)

Furthermore, this behavior seems correct to me. Please check "man postfix":

SYNOPSIS
       postfix [-Dv] [-c config_dir] command

where "command" is one of check, start, stop, abort etc. There is no quiet-quick-start

Revision history for this message
Scott Kitterman (kitterman) wrote :

That exhausts my ideaa on the subject. Hopefully Lamont will look in and give some advice.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for postfix (Ubuntu) because there has been no activity for 60 days.]

Changed in postfix:
status: Invalid → New
Revision history for this message
LaMont Jones (lamont) wrote :

This bug is intermittently reported against postfix, and I have no idea why the reporters' systems wind up with the wrong copy of /etc/postfix/postfix-script installed (it's not the one that the package delivers.) Reinstalling the package seems to fix the problem as well. This leads me to believe that maybe the reporter is manually building/installing postfix from upstream source, rather than from the package? dunno.

What we need is a good way to actually reproduce the issue

Changed in postfix:
assignee: nobody → lamont
status: New → Incomplete
Changed in postfix:
status: Unknown → New
Changed in postfix:
status: New → Incomplete
Revision history for this message
Scott Kitterman (kitterman) wrote :

Moving off of Incomplete since this shouldn't get auto expired.

Changed in postfix:
status: Incomplete → Confirmed
Revision history for this message
Tim Bruce (kb0odu) wrote :

I was trying to fix a postfix configuration install by doing a apt-get remove postfix, removing /etc/postfix, and doing an apt-get install postfix.

It seems like the apt-get install postfix does not do all the same steps as on an initial install. I have not yet been able to fully confirm this in my testing yet. But maybe it will give someone more experienced the opportunity to further debug / troubleshoot.

Tim
kb0odu

Revision history for this message
Tim Bruce (kb0odu) wrote :

I should have included the following information:

Ubuntu Server v7.10
Installed inside a VMware instance.

Basic install (just openssh and internet mail).

One of the clues (which didn't help me solve it, but gave me some places to look) was: https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/42947

The dpkg remove postfix and dpkg purge postfix didn't fully work. This might have been the result of some dependency issues with dovecot (which is where my problems were).

Tim

Revision history for this message
Scott Kitterman (kitterman) wrote :

When you manually remove conffiles (anything in /etc) dpkg remembers that and assumes you don't want them when you reinstall the package. So what you report in your first comment is the package management system behaving as designed. dpkg purge followed by an install should restore the config files. So far you are not experiencing any postfix related bugs. If you do, please file them as new bugs unless you're sure you've got the same issue.

Revision history for this message
Tony Green (ubuntu-beermad-deactivatedaccount) wrote :

I have just installed 8.10 and have suffered exactly the same problem.

Due to my attempt at upgrading an existing system having failed spectacularly, this was a completely clean install, so the faulty init.d file has to have come from the package.

The install also failed to create the /var/spool/postfix/public/pickup FIFO.

Revision history for this message
Ivars Strazdiņš (ivars-strazdins) wrote :

If this can help anyhow - I am having the same problem on clean install with 8.10 Ubuntu server.

Revision history for this message
Angelo (gate-keeper) wrote :

in /etc/init.d/postifx, line 98 need to be changed from: if start-stop-daemon --start --exec ${DAEMON} -- quiet-quick-start; then
into: if start-stop-daemon --start --exec ${DAEMON} start; then

also line 111 from: if ${DAEMON} quiet-stop; then
into: if ${DAEMON} stop; then

This worked for me on ubuntu 8.10 server

angelo

Mathias Gug (mathiaz)
Changed in postfix (Ubuntu):
importance: Undecided → Low
importance: Low → Medium
Revision history for this message
rusivi2 (rusivi2-deactivatedaccount) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. I noticed that the package version your bugging is updated in Maverick. Please update via www.ubuntu.com repost a detailed error report, and update the bug status. Thanks!

Revision history for this message
Phillip Susi (psusi) wrote :

Without a way to reproduce the problem, and the fact that the conf file in the package does not look like that, I don't think we have a bug here. Combined with a lack of input for several years, I think it's time this is put to rest.

Changed in postfix (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.