Re: [OT] Re: found a bug on postfix 2.9.1

2012-03-07 Thread Wietse Venema
Eliezer Croitoru:
 On 07/03/2012 02:33, Wietse Venema wrote:
  Eliezer Croitoru:
  i dont care about any init scripts on whatever else then when there is
  this specific problem of mismatching binding an ip that dosnt exist to
  be checked using the postfix check method on terminal and not only on 
  log.
 
  Sorry, only the master daemon knows that it can't access the IP address.
 ok but it wont stop using postfix stop

When the master daemon is not running:

# postfix stop
postfix/postfix-script: fatal: the Postfix mail system is not running

What result did you expect?

Wietse


[OT] Re: found a bug on postfix 2.9.1

2012-03-06 Thread Michael Orlitzky
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.


Re: [OT] Re: found a bug on postfix 2.9.1

2012-03-06 Thread Wietse Venema
Michael Orlitzky:
   backup2 ~ # killall -9 /usr/lib64/postfix/master
   backup2 ~ # /etc/init.d/postfix start
* WARNING: postfix has already been started

That is a bug in an init script, and is the responsibility
of the OS-specific maintainer. Postfix does not provide
init/upstart/systemd/launchpad/whatever scripts.

Wietse


Re: [OT] Re: found a bug on postfix 2.9.1

2012-03-06 Thread Eray Aslan
On Tue, Mar 06, 2012 at 02:30:59PM -0500, Michael Orlitzky wrote:
 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

You get this error because your system thinks postfix is running because
the init script exited successfully because postfix start exited
successfully (but postfix bailed out with wrong configuration).  With
postfix status check added, the init script, hence your system, would
work as expected and you won't be getting the above or similar errors,
i.e. there would be no need for the zap  start workaround.

Downside:
It would take ~1sec more to start up postfix *for everyone* - one has to
wait a bit before running postfix status after postfix start.

So, yes it is not a clear cut decision but for different reasons.

This is getting really off topic.

-- 
Eray Aslan


Re: [OT] Re: found a bug on postfix 2.9.1

2012-03-06 Thread Wietse Venema
Eray Aslan:
 On Tue, Mar 06, 2012 at 02:30:59PM -0500, Michael Orlitzky wrote:
  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
 
 You get this error because your system thinks postfix is running because
 the init script exited successfully because postfix start exited
 successfully (but postfix bailed out with wrong configuration).  With
 postfix status check added, the init script, hence your system, would
 work as expected and you won't be getting the above or similar errors,
 i.e. there would be no need for the zap  start workaround.
 
 Downside:
 It would take ~1sec more to start up postfix *for everyone* - one has to
 wait a bit before running postfix status after postfix start.

So you need a way for postfix start that returns status 0 if the
master(8) daemon initalizes successfully, and non-zero otherwise.

I think this can be done by starting the master as a foreground
process.  The foreground master forks a child process that will
become the master daemon that runs as a background process. 

The foreground master process waits for the all is OK signal from
the child process. When that happens, the foreground process
terminates with a 0 status, causing postfix start to return a 0
status.  This will normally take a fraction of a second.

In case of problems (no response from child, child terminates) the
foreground process terminates with non-zero status, and postfix
start reports an error, and returns a non-zero exit status.

Will that work?

Wietse


Re: [OT] Re: found a bug on postfix 2.9.1

2012-03-06 Thread Eray Aslan
On Tue, Mar 06, 2012 at 04:01:47PM -0500, Wietse Venema wrote:
 So you need a way for postfix start that returns status 0 if the
 master(8) daemon initalizes successfully, and non-zero otherwise.

Correct.

 I think this can be done by starting the master as a foreground
 process.  The foreground master forks a child process that will
 become the master daemon that runs as a background process. 
 
 The foreground master process waits for the all is OK signal from
 the child process. When that happens, the foreground process
 terminates with a 0 status, causing postfix start to return a 0
 status.  This will normally take a fraction of a second.
 
 In case of problems (no response from child, child terminates) the
 foreground process terminates with non-zero status, and postfix
 start reports an error, and returns a non-zero exit status.
 
 Will that work?

Yes, that will work.  Thank you.

-- 
Eray Aslan


Re: [OT] Re: found a bug on postfix 2.9.1

2012-03-06 Thread Eliezer Croitoru

On 06/03/2012 21:30, Michael Orlitzky wrote:

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
i dont care about any init scripts on whatever else then when there is 
this specific problem of mismatching binding an ip that dosnt exist to 
be checked using the postfix check method on terminal and not only on log.


by writing the bug i do hope this simple guy that will look for the 
problem will understand what could he missed.


Thanks,
Eliezer


So the benefit is not clear-cut.






Re: [OT] Re: found a bug on postfix 2.9.1

2012-03-06 Thread Wietse Venema
Eliezer Croitoru:
 i dont care about any init scripts on whatever else then when there is 
 this specific problem of mismatching binding an ip that dosnt exist to 
 be checked using the postfix check method on terminal and not only on log.

Sorry, only the master daemon knows that it can't access the IP address.

To find out if Postfix runs, use postfix status. Don't use the
crap scripts from Linux maintainers. To find out why Postfix
does not run , read the logfile.

Wietse


Re: [OT] Re: found a bug on postfix 2.9.1

2012-03-06 Thread Eliezer Croitoru

On 07/03/2012 02:33, Wietse Venema wrote:

Eliezer Croitoru:

i dont care about any init scripts on whatever else then when there is
this specific problem of mismatching binding an ip that dosnt exist to
be checked using the postfix check method on terminal and not only on log.


Sorry, only the master daemon knows that it can't access the IP address.

ok but it wont stop using postfix stop

Eliezer


To find out if Postfix runs, use postfix status. Don't use the
crap scripts from Linux maintainers. To find out why Postfix
does not run , read the logfile.

Wietse




Re: [OT] Re: found a bug on postfix 2.9.1

2012-03-06 Thread Viktor Dukhovni
On Tue, Mar 06, 2012 at 04:01:47PM -0500, Wietse Venema wrote:

 So you need a way for postfix start that returns status 0 if the
 master(8) daemon initalizes successfully, and non-zero otherwise.
 
 I think this can be done by starting the master as a foreground
 process.  The foreground master forks a child process that will
 become the master daemon that runs as a background process. 
 
 The foreground master process waits for the all is OK signal from
 the child process. When that happens, the foreground process
 terminates with a 0 status, causing postfix start to return a 0
 status.  This will normally take a fraction of a second.
 
 In case of problems (no response from child, child terminates) the
 foreground process terminates with non-zero status, and postfix
 start reports an error, and returns a non-zero exit status.
 
 Will that work?

It'll could be an inconvenience for the folks at Apple, who start
master(8) directly via launchd.  However, since they've made no
attempt to have their patches adopted, ...  it is hard to take
their interests into account. Probably provided master -d continues
to run in the foreground, their stuff will not break in new ways. :-)

-- 
Viktor.