> 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. > > 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?
@Murray: Thanks for the proposal, SIGUSR1 would be appropriate. I just opened a feature request. @Todd: >> We wrote an open source perl daemon and a perl client to manage >> dkim-filter settings, see http://dkim-connector.agitos.de/trac/ > > I see you have a newsletter, but do you also having mailing lists? If the dkim-connector project matures (I think this will depend on the feedback of users - we don't have much of it at time) we should transfer this project to sourceforge and use the SF-tools including the mailing list feature. @Tonni: > On my Red Hat-derived SysV-compatible dkim-milter > machines I can do "service dkim-milter restart" In dkim-connector we need some uniform way to reload dkim-filter - e.g. there is no service command on my Debian system. In addition open connections to dkim-milter could possibly remain while the configuration is reloaded. Flo ------------------------------------------------------------------------- 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
