On 2/25/2011 8:16 AM, Wietse Venema wrote:
The problem with this approach is that Postfix is not one program,
like named, apache, etc., and that simply starting one master daemon
is insufficient as it skips all the start-up repair and sanity checks.
That's why i said it may be useful to have a simple
"dispatcher/wrapper" which only is started to call "postfix start" and
keeps running to keep upstart happy and calls "postfix stop/restart"
when advised to do so by upstart. With this the supported way of
starting/stopping is possible *and* upstart could be used without
problems. The only problem to solve is the non-terminating behaviour
required by upstart, all other startup work can be done as usual
behind the scene.
I suppose you mean something like this:
postfix upstart
Run in "upstart pacifier" mode, and do not terminate.
Execute the equivalents of "postfix start" and "postfix
stop" as appropriate, and do nothing in the mean time.
Just using up an idle process slot to keep upstart happy.
Wietse
Wietse
Since Upstart is new to me I decided to read about it: "[The
shortcomings of sysvinit] leaves it unable to handle various tasks on a
moderndesktop computer
<http://en.wikipedia.org/wiki/Desktop_computer>elegantly, including: The
addition or removal ofUSB pen drives
<http://en.wikipedia.org/wiki/USB_pen_drive>and other portable storage /
network devices while the machine is running..." (Wikipedia) 'As the
primary focus of this specification is dealing with modern hardware and
its "coming and going" nature' (Ubuntu)
So the meta-issue appears to be a collision in design between typical
desktop and server design models. Sort of. Desktops still have long
running services too that should never "go awry" (wording from Fedora
upstart doc page).
The (*flame retardant leggings put on*) Windows service model seems much
better, wherein each service must implement a defined start/stop
interface. Any service management tool doesn't need a tight grip on a
collection of child processes, just uses this simple interface. Breaking
the daemonization model is just odd to me.
In any case the upstart page makes it clear that it will be
backward-compatible with sysv for a while during this transition, so
there doesn't seem to be any rush. Perhaps someone can advocate for a
true service model in the meantime for things that *don't* change and
*should definitely* happen right at boot?
-Daniel
