Zitat von Wietse Venema <wie...@porcupine.org>:
lst_ho...@kwsoft.de:Zitat von Wietse Venema <wie...@porcupine.org>: > Wietse Venema: >> lst_ho...@kwsoft.de: >> > Zitat von Wietse Venema <wie...@porcupine.org>: >> > >> > > lst_ho...@kwsoft.de:>> > >> The "problem" is more of that distribution like Ubuntu and Redhat are>> > >> moving to "upstart" for boot and starting services/daemons. The main >> > >> difference for the started services is that upstart need the program > > Is there any reason they can't do this: > > Postfix "job" script: > > pre-start exec postfix start > post-stop exec postfix stop > > With this, the system will do the work for them, and everything > uses stable documented interfaces. I'm just on the way learning the new concepts of upstart... As far as i understand the common way is to not detach as it is done in the common way but run in foreground to keep contact with upstart (init) so status can be easily collected. It should be possible toI'll repeat, this does not work with Postfix multi-instance support, which requires multiple master daemons.
Agreed and understanded.
They can use this: pre-start exec postfix start pre-stop exec postfix stop
This has the drawback that "postfix start" terminates after Postfix is started so as said upstart will report Postfix as "waiting" (for the next event) instead of "running".
Or they can use a "postfix upstart" pacifier which does "postfix
start" then does nothing until shutdown:
exec postfix upstart
pre-stop exec postfix stop
That was the construct i tried to explain. A wrapper/pacifier whatever is needed which does not terminate but does nothing until a "stop" or some other event arrives.
They should not start and stop the master directly. Among other things, that does not work with multi-instance support.
Agreed and understanded. Regards Andreas
smime.p7s
Description: S/MIME Cryptographic Signature
