http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5419
------- Additional Comments From [EMAIL PROTECTED] 2007-06-29 06:56 ------- > Unfortunately it's not possible to find out exactly what the "real" > ARGV array was when the script was started; ... > instead, what the change does is check the #!line on the perl script > [...] btw, this is safer than the alternative approach: 'Can the correct > perl interpreter not be specified with PERL_BIN when making the Makefile > the problem with this is that the user could install using /usr/bin/perl, > then later decide to run spamd using /usr/local/bin/perl (or whatever). Yes, these are some of the problems associated with restarting a server with HUP. Without trying to influence a decision here, let me describe how I handled this in amavisd - a couple of times unsuccessfully bumping into issues like described here an others, then finally abandoned it and took another more universal approach (no mountain is so insurmountable that one could not walk AROUND it). Additional difficulties (that I had to deal with) with HUP are: - if a process chrooted itself, it can not escape jail for a restart, which would require config file and all Perl modules to be installed within a jail, which complicates things and throws away many benefits of running chrooted; - if a process dropped all privileges it can not regain them; - somehow I could not solve the problem when binding to a specific socket was requested and the config changed, a restarted process after a HUP just hung (must be a bug somewhere (maybe Net::Server), don't know). Anyway, for those running amavisd chrooted or when config file was not accessible after changing UID, the HUP way of restarting was not possible at all. So instead of having to cater for two types of usage, I chose to only support one universal way: When the amavisd command is run with a command-line option 'restart' (or 'stop'), the program first tries to find existing daemon process and shut it down, nicely at first (SIGTERM), then with force if it does not respond after some time. After it has been determined the old daemon really went away, and a 'restart' (or 'start') is specified, the interactive process promotes itself to become a new daemon, just as with a normal initial start. This approach also works when a currently running daemon is unresponsive. As a demon is always born out of a shell command (not from another daemon), its environment, perl interpreter and options is always predictable (explicit), either during initial start or after a restart. A possible transition path could be to still support the HUP restarts, but also provide some restarting and/or shutdown command line option. Anyway, just food for thought (avoiding potential future problems) ... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
