Michael Zimmermann wrote the following on 30.11.2006 23:49 :
> Dear list,
>
> after running a while sqlgrey stops working. The logs show, that it
> restarted, but it's
> port is closed after the restart.
It could be the old sqlgrey process still living and bound to the socket
when the new one comes up (the underlying Net::Server::Multiplex library
has already demonstrated this behaviour on my systems). My solution was to :
1/ add a long enough sleep between the TERM signal (sqlgrey -k or
killall sqlgrey for example) and the restart.
2/ use Nagios to monitor the port (check_tcp) and be warned if it goes down.
>
> X-Greylist: delayed 00:05:05 by SQLgrey-1.7.4
Good I know the version -:)
> Use of uninitialized value in unlink at /usr/sbin/sqlgrey line 2577.
Odd : it seems the pidfile location is undefined when trying to kill the
daemon.
>
> The sqlgrey is just started manually via a
> # nohup sqlgrey &
>
Ok I know why SQLgrey doesn't find a pidfile: it doesn't know it is
running as a daemon. You should start it with 'sqlgrey -d' and kill it
with 'sqlgrey -k' both as root (they need read/write access to
/var/run/sqlgrey.pid and change to sqlgrey's uid later anyway).
> or am I wrong about that, and the sqlgrey needs to be entered into the
> master.cf to be started as a postfix-service?
>
No, it doesn't support running from master.cf (until someone codes the
support for this).
To sum up :
- first try the 'sqlgrey -d' / 'sqlgrey -k' start/stop method,
- then if you still have problems when restarting SQLgrey, make a short
pause (one second should be enough, increase if you still have problems)
between the stop and the start.
Anyway, why do you need to restart SQLgrey? There are reasons such as
DBD-driver leaks with some versions of the PostgreSQL DBD driver for
example, but they should be exceptions.
Lionel.
|
