Hm, this would need quite some logic change to make Conf.pm feed back the list 
of currently used config files and directories to spamd which would need to 
incorporate FAM into its event loop. As I'm currently modding on Conf.pm 
anyway, I think I could implement it, but it looks like it would get hairy. 
 
Theoretically it would be a nice feature, but 'kill -HUP' already works for 
spamd and that's the "real" UNIX way of reloading config files; I know that I 
myself sometimes change stuff in the config files and save the file in between 
(just because I am used to save files every few seconds) so if spamd noticed 
that change, it might either find a broken config or reload every few seconds 
(evertime I hit "save") with another config... 
 
I tend to close this as WONTFIX but let's see what the other devs think :) If 
spamd got FAM support, it would be an optional feature which had to be enabled 
in the config file and would default to off. 

I agree with Malte on this one.

Subject: Re:  enhancement: modify spamd to monitor changes to /etc/mail/spamassassin and reload config 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


- -1 from me.  FAM is not widely available.

I would suggest that we could do something similar by monitoring
modification times on the .cf files and the cf directories, then
statting them periodically (like after each scan).  But I'd
be concerned that would slow things down quite a lot.

- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFAK7uQQTcbUG5Y7woRAiZDAKDi70R1QRVbIfNrWDSEWVmy8QuU+ACeIb/a
rtfD1zxBxtc2M2ruVxYnlaU=
=1HRW
-----END PGP SIGNATURE-----

Subject: RE:  enhancement: modify spamd to monitor changes to /etc/mail/spamassassin and reload config


After following the discussion, and thinking this over a bit, I'm going
to -1 my
proposed enhancement. My motivation for having this feature was to lower the
support overhead ("did you restart spamd?") and to help overcome the
time/two
that I'd forgotten to restart spamd, but it looks like this sort of
automation
is difficult to achieve given current constraints.

Perhaps one 'fix' would be to move the things that are often modified the
most
(explicit whitelists/blacklists) into a database and provide tools to update
them.
Arguably some of the more
popular rulesets that are periodically updated (bigevil, and evilnums come
to mind) would be better suited to a database, and a single eval rule for
each that looks up url's and postal addresses in the database.
I don't know if this principal could be extended to the SA ruleset in
general. The closest analog that I know of is sendmail's access.db. I think,
but am not sure, that makemap for example, likely sends a signal to sendmail
telling it that one of the maps has been modified, because it doesn't
require
that the user manually restart sendmail when a new map has been created.

Subject: Re:  enhancement: modify spamd to monitor changes to /etc/mail/spamassassin
 and reload config

bugzilla-daemon@bugzilla.spamassassin.org wrote:
> http://bugzilla.spamassassin.org/show_bug.cgi?id=3033
> 
> gary@intrepid.com changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Summary|enhancement: modify spamd to|enhancement: modify spamd to
>                    |monitor changes to          |monitor changes to
>                    |/etc/mail/spamassassin and  |/etc/mail/spamassassin and
>                    |relogd config               |reload config

-1 from me too. If I want a program to restart/reload, I'll fire off the 
init.d script or send a HUP. I don't want daemons unexpectedly reading 
configurations.

OTOH, it might be useful if someone were sharing the config files over 
an NFS mount across several machines.

If someone does take the time to implement it, I'd highly recommend that 
it be a configurable option that defaults to disabled.

--Rich

Ok, I think we have found a consensus ;-) 

Subject: Re:  enhancement: modify spamd to monitor changes to /etc/mail/spamassassin and reload config 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>-1 from me too. If I want a program to restart/reload, I'll fire off the 
>init.d script or send a HUP. I don't want daemons unexpectedly reading 
>configurations.

That's a very good point -- say I'm editing a rules file, accidentally
hit "W", and write a file with a half-written rule -- that would
take effect immediately.  Not a good thing IMO

- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFAK892QTcbUG5Y7woRAhaqAJ9b7Kj4gOTyAgzLaNviZm5OdxAcpQCcCvNC
kU4N63l01UPbExcGvJSVr9w=
=3RYH
-----END PGP SIGNATURE-----

Subject: Re:  enhancement: modify spamd to monitor changes to /etc/mail/spamassassin and reload config

On Thu, Feb 12, 2004 at 11:09:50AM -0800, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> http://bugzilla.spamassassin.org/show_bug.cgi?id=3033
> 
> 
> 
> 
> 
> ------- Additional Comments From jm@jmason.org  2004-02-12 11:09 -------
> Subject: Re:  enhancement: modify spamd to monitor changes to /etc/mail/spamassassin and reload config 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> >-1 from me too. If I want a program to restart/reload, I'll fire off the 
> >init.d script or send a HUP. I don't want daemons unexpectedly reading 
> >configurations.
> 
> That's a very good point -- say I'm editing a rules file, accidentally
> hit "W", and write a file with a half-written rule -- that would
> take effect immediately.  Not a good thing IMO

Or just the fact that it'd be possible for spamd to get a partial file
while your editor was writting it.  (How many editors do automic file
updates?)  

-1

(Hey, wait, I'm not a Dev.)

<g>

Okokok folks, calm down; more than closing it as WONTFIX I can't do :) 

Subject: Re:  enhancement: modify spamd to monitor changes to /etc/mail/spamassassin and reload config

> -1
> 
> (Hey, wait, I'm not a Dev.)

We welcome votes from non devs, but they just hold no numerical
weight. It's good to see a consensus within the community, and your
opinions matter, so feel free to vote.

*** Bug 4210 has been marked as a duplicate of this bug. ***