Murray S. Kucherawy skrev, on 04-10-2007 21:01: > On Thu, 4 Oct 2007, Florian Sager wrote: >> I expected a SIGHUP to the PID of dkim-filter would result in a reload >> of the configuration files. Instead SIGHUP terminates dkim-filter: >> [...] > > SIGHUP is currently intercepted by libmilter, not by code in dkim-filter > itself. libmilter interprets it as a shutdown signal. > > To reload configurations, I generally use the AutoRestart feature and then > kill the child process rather than the parent. The child will exit and > the parent will spawn a new child which then re-reads the configurations. > Unfortunately the parent's pid is the one stored via the "-P" switch, not > that of the child. > > You can open a feature request via SourceForge if you like. It might be > better/safer to use SIGUSR1 to arrange for a reload rather than SIGHUP in > order to avoid that conflict. Would that be acceptable?
I might be obstreperous (in fact I most certainly am) but what the heck does it matter? On my Red Hat-derived SysV-compatible dkim-milter machines I can do "service dkim-milter restart" and I get a stop and start. Bingo. What is dkim-filter caching or whatever it is that make a reload necessary? It's not like a number of other services (like Postfix or OpenLDAP, for example), where a stop+start can ruin connections and wipe out caches. --Tonni -- Tony Earnshaw Email: tonni at hetnet dot nl ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ dkim-milter-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
