Bugzilla Bug 88574

The provided init script does not appropriate dependency checking for proper
startup:

In /etc/init.d/gld
depend() {
        need
        use dns
        before postfix
}

should be

depend() {
        need net
        use dns mysql
        before postfix
}

need -> "net"  if mysql database is not local
use -> "mysql" to start AFTER local mysql database

Without this and not running / reachable mysql database the daemon dies at
startup and leaves you in worst case with a non functional postfix which
rejects all email and this is no fun... ;-)

Reproducible: Always
Steps to Reproduce:
1.setup postfix, mysql, gld
2.boot up
3.gld is not started if mysql is not running

Actual Results:  
postfix rejects email

Expected Results:  
proper startup of gld, functional greylisting for postfix

Created an attachment (id=55965) [edit]
my init script for gld

Since the startup is also time critical, I

Created an attachment (id=55965) [edit]
my init script for gld

Since the startup is also time critical, I´ve added a "sleep 3" to give mysql a
little time to load so that gld can connect to the service. This is a bit ugly
since heavy dependend on the local maschine if this is enough time to load all
mysql databases...
It should be replaced by a loop that checks for the mysql pid, maybe issuse a
"sql ping" with connection data in gld.conf and if this succeds, fire up gld...

Okay, I've made these changes, however, I don't see the MySQL not being
properly started as a problem we should have to fix in the gld init script. The
MySQL init script shouldn't eend $? before it's running completely. Feel free
to reopen if you still feel differently.

Thanks for the fixes, Alexander!

After having time to look further into init scripts, I have to agree that the
mysql init script is the place to fix that time critical startup since other
applications are highly likely to be affected too...
Some last thing on gld before this goes stable, a dedicated user with least
priviledges for this program should be generated at install time, but I will
file a new bug regarding this... (#90468)

bug referred in #c3 is bug# 90471