Wietse Venema via Postfix-users wrote in
<[email protected]>:
|Michael Tokarev via Postfix-users:
|> I'm revisiting debian packaging of postfix, and noticed that a lot \
|> of stuff is done
|> in quite sophisticated, twisty, or outright wrong way due to a simple \
|> issue: many
|> postfix utilities require certain parameters to be set.
|>
|> One example is[.]
...
|What about this: don't run any Postfix commands until the machine
|is ready. I prefer to start any Postfix activity only after DNS,
|networking, etc. are configured/running. That has always workded
|well for me.
Yes, this is why my personal system driver does this:
postfix__init() {
name=postfix
pid=
if [ -n "${STARTUP}" ]; then
^ that is non-empty upon system boot
echo >&2 'In startup; postfix is picky, sleeping 5 to let
devices settle'
sleep 5
^ this is "hanebüchen", ie, brute force sleeping by 5 seconds.
fi
prog=$(command -v ${name} 2>/dev/null)
}
postfix_start() { postfix__init; eval ${prog} start ${POSTFIX_ARGS}; }
postfix_stop() { postfix__init; ${prog} stop; }
postfix_status() {
# As postfix does not use stdout but console, no
# postfix__init
# ${prog} status 2>&1
name=postfix
eval $(postconf daemon_directory data_directory | tr -d '[ ]')
prog=${daemon_directory}/master
pid=${data_directory}/master.lock
daemons__stat_and_dog n
}
postfix_watchdog() {
postfix__init
${prog} status >/dev/null 2>&1
[ ${?} -ne 0 ] && postfix_start
}
This works for years, but is very special. (It is worth it
though!) (This runs asynchronously.)
...
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|And in Fall, feel "The Dropbear Bard"s ball(s).
|
|The banded bear
|without a care,
|Banged on himself for e'er and e'er
|
|Farewell, dear collar bear
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
