hrm.  well, I don't believe it's ident related, since that just verifies "spamc
username == ident username".  moving to the 3.0.0 queue for more investigation.

Subject: Re:  Wrong bayes and AWL files being opened

On Mon, Jul 12, 2004 at 07:44:38AM -0700, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> hrm.  well, I don't believe it's ident related, since that just verifies "spamc
> username == ident username".  moving to the 3.0.0 queue for more investigation.

can you check to see that the problem still exists without the ident
bit in there?  thanks. :)

This is the same as the problem aleady reported in bug 3525, and is still
happening with SVN 22750

Created attachment 2119 [details]
test patch

in digging around, the only thing I can come up with is that in spamd,
sed_path_cache is backed up w/out the bayes/etc path (forcably removed via
compile_now), then a message processing would set it, then the previous values
are restored but since the bayes/etc wasn't there before the new version isn't
overwritten.

so this patch has copy_config() blow away the destination's sed_path_cache
before restoring the previously backed up values.  this should let us keep the
benefit of the cache without not overwriting new data that gets stored after
the backup.

can the people seeing this issue please try out the patch?  thanks. :)

(btw: I've seen an occasional "autolearn=failed" on my box, which could very
well be caused by this issue...  I'll be trying the patch as well to see if the
# of failed occurances goes down.)

I still get the autolearn=failed messages, btw.

/me continues digging

w00t!  I did some more debugging and the test patch does fix the "wrong path" issue for me (most of 
the autolearn=failed states I was seeing, although I still get some, but that's another ticket if it's not a 
locking issue or something not bad...)

Pre patch:
(PID: EUID, cache key => cache value)

31838: EUID 101, __userstate__/bayes => /home/felicity/.spamassassin/bayes
31838: EUID 101, __userstate__/bayes_journal => /home/felicity/.spamassassin/bayes_journal
31839: EUID 101, __userstate__/bayes => /home/felicity/.spamassassin/bayes
31839: EUID 101, __userstate__/bayes_journal => /home/felicity/.spamassassin/bayes_journal
31839: EUID 123, failed, __userstate__/bayes => /home/felicity/.spamassassin/bayes
31839: EUID 123, failed, __userstate__/bayes_journal => /home/felicity/.spamassassin/bayes_journal
31838: EUID 123, failed, __userstate__/bayes => /home/felicity/.spamassassin/bayes
31838: EUID 123, failed, __userstate__/bayes_journal => /home/felicity/.spamassassin/bayes_journal
31839: EUID 107, failed, __userstate__/bayes => /home/felicity/.spamassassin/bayes
31839: EUID 107, failed, __userstate__/bayes_journal => /home/felicity/.spamassassin/bayes_journal
31838: EUID 107, failed, __userstate__/bayes => /home/felicity/.spamassassin/bayes
31838: EUID 107, failed, __userstate__/bayes_journal => /home/felicity/.spamassassin/bayes_journal

so we can see both pids get my cache state, then whenever a different euid comes around (therefore 
different home dir and different required path), it gets a failed state and the cache values are still 
pointing at me.  with the patch:

2152: EUID 101, __userstate__/bayes => /home/felicity/.spamassassin/bayes
2152: EUID 101, __userstate__/bayes_journal => /home/felicity/.spamassassin/bayes_journal
2153: EUID 101, __userstate__/bayes => /home/felicity/.spamassassin/bayes
2153: EUID 101, __userstate__/bayes_journal => /home/felicity/.spamassassin/bayes_journal
2152: EUID 107, __userstate__/bayes => /home/timex/.spamassassin/bayes
2152: EUID 107, __userstate__/bayes_journal => /home/timex/.spamassassin/bayes_journal
2153: EUID 123, __userstate__/bayes => /home/karen/.spamassassin/bayes
2153: EUID 123, __userstate__/bayes_journal => /home/karen/.spamassassin/bayes_journal

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

+1. Works great now. Thanks.

ok, changing to review status. yea. :)

+1

+1 appears to be okay, I'm not set up to test at the moment ... so I didn't

committed.  r22886. :)

Damn, I've been noticing missing BAYES tags on some incoming mails, and upon
investigation I'm still seeing this even with the above patch. :(

Strictly speaking, this is a solution for 3525 and I'm seeing it again today
because I migrated everything to a central virtual-user-dir configuration.

However, after some looking through I realised that if we have
--virtual-config-dir set, then $setuid_to_user is set to false,
and to cut a short story long, ultimately we do not actually call
copy_config at all.

I've attached a patch which resolves this.

Created attachment 2130 [details]
call copy_config also when virtual-config-dir is set

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

hrm.  so the issue with virtual-config-dir is _specifically_ the sed_cache_path thing?  ie: no 
configuration options change with the use of that option, right?

if so, I'm thinking we should avoid the whole copy_config thing, since it's much more resource intensive 
than "delete $...->{sed_cache_path};"

to answer my own question, yeah, virtual-config-dir lets the virtual users do configs too, so 
copy_config() would be good there.

so +1 on 2130 :)

+1

+1

ok, committed 2130.  r22947