(In reply to comment #0)
> I'm unsure if the change to a die for the lack of a user_dir was intentional. 
> So anyone know if/why/etc?

it was not, I think.
here's the specific error message:

Dec 30 09:35:24 mail1 mimedefang-multiplexor[4448]: Slave 0 stderr: config:
path "/root/.spamassassin" is inaccessible: Permission denied
Dec 30 09:35:24 mail1 mimedefang-multiplexor[4448]: Slave 0 stderr: config:
error accessing /root/.spamassassin: Permission denied
Dec 30 09:35:24 mail1 mimedefang-multiplexor[4448]: Slave 0 died prematurely
-- check your filter rules
Dec 30 09:35:24 mail1 mimedefang[9301]: Error from multiplexor: ERR No
response from slave
Dec 30 09:35:24 mail1 mimedefang-multiplexor[4448]: Reap: slave 0 (pid 4449)
exited normally with status 13 (SLAVE DIED UNEXPECTEDLY)
Dec 30 09:35:24 mail1 mimedefang-multiplexor[4448]: Slave 0 resource usage:
req=1, scans=1, user=0.316, sys=0.012, nswap=0, majflt=0, minflt=7034,
maxrss=0, bi=0, bo=0

( http://www.mail-archive.com/mimedefang@lists.roaringpenguin.com/msg13454.html )


see line 1847 in http://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/SpamAssassin.pm?annotate=894117 for the change details:

1839 	felicity 	410643 	 if (!$self->{dont_copy_prefs}) {
1840 	  	  	dbg("config: using \"$fname\" for user state dir");
1841 	felicity 	410676 	}
1842 	felicity 	410643 	
1843 	mmartinec 	697056 	my $stat_errn = stat($fname) ? 0 : 0+$!;
1844 	  	  	if ($stat_errn == 0 && !-d _) {
1845 	  	  	die "config: $fname exists but is not a directory\n";
1846 	  	  	} elsif ($stat_errn != 0 && $stat_errn != ENOENT) {
1847 	  	  	die "config: error accessing $fname: $!\n";
1848 	  	  	} else { # does not exist, create it
1849 	felicity 	410676 	# not being able to create the *dir* is not worth a warning at all times
1850 	mmartinec 	568336 	eval {
1851 	  	  	mkpath($fname, 0, 0700); 1;
1852 	  	  	} or do {
1853 	  	  	my $eval_stat = $@ ne '' ? $@ : "errno=$!"; chomp $eval_stat;
1854 	  	  	dbg("config: mkdir $fname failed: $eval_stat");
1855 	  	  	};
1856 	jmason 	3805 	}

so it appears to have been Mark's toughening-up of error conditions change, r697056:

http://svn.apache.org/viewvc?view=revision&revision=697056
http://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/SpamAssassin.pm?r1=697055&r2=697056&

Revision 697056 - (view) (download) (annotate) - [select for diffs]
Modified Fri Sep 19 11:26:46 2008 UTC (15 months, 2 weeks ago) by mmartinec
File length: 65312 byte(s)
Diff to previous 690090 (colored)

[Bug 5981] Improved error detection and reporting

That's https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5981 .


I think the appropriate fix here would be to change that die() to a dbg(); as the
following comment notes, failure to create the dir there is not even worth a
warning at all times, let alone a die().  We handle write failures appropriately
later, when saves of the journal files/databases are attempted.

I'll attach a patch.

Created attachment 4619 [details]
possible fix

MD folks -- does this help?

I just asked the MD author to review and/or forward for MD Users to test.

Thanks.

(In reply to comment #3)
> I just asked the MD author to review and/or forward for MD Users to test.
> 
> Thanks.

ok, I'm assuming no news is good news.  let's get votes on this...

+1

+1

I don't mind the proposed change die->dbg, although the original change
was not unintentional. As an admin I'd be worried if some application tries
to write into /root (but fails), or if what is supposed to be a directory
turns out to be a regular file or worse (pipe, special device) - and
would prefer to be boldly notified by the application about such a failure.

(In reply to comment #6)
> +1
> 
> I don't mind the proposed change die->dbg, although the original change
> was not unintentional. As an admin I'd be worried if some application tries
> to write into /root (but fails), or if what is supposed to be a directory
> turns out to be a regular file or worse (pipe, special device) - and
> would prefer to be boldly notified by the application about such a failure.

+1 - Also, the dbg to die change being an API change that is affecting real-world applications using the API, the change should be considered carefully and if necessary documented in an incompatibilities section / Changes / Readme.  I'm not opposed to the change but would recommend it delay the release of 3.3.0 to give API integrators a chance to prepare compatible releases.

Amavis and MIMEDefang, for example, come to mind.

FYI, DFS of MD has also given lazy consensus to the die to dbg change.

> delay the release of 3.3.0 to give API integrators a chance to prepare
> compatible releases.

We are back to the old 3.2.5 handling after the patch is applied.

> Amavis and MIMEDefang, for example, come to mind.

Amavisd works fine with 3.3.0 since 2.6.2 (a December 2008 release).

> FYI, DFS of MD has also given lazy consensus to the die to dbg change.

Thanks to David and the MD folks to test with the 3.3.0-rc1 (and to
quickly respond with a rc with a workaround). If there were other issues,
we'd probably hear by now.

The Bug 5981 change (r697056) has been in trunk since 2008-09-19 (16 months),
including the alpha (July 2009), beta and rc1 releases. I'd say that gave
ample time for testing.

(In reply to comment #8)
> > delay the release of 3.3.0 to give API integrators a chance to prepare
> > compatible releases.
> 
> We are back to the old 3.2.5 handling after the patch is applied.
> 
> > Amavis and MIMEDefang, for example, come to mind.

Clarify:  If you want the die() put back in, then delay the 3.3.0 release and document.

Bug 6268: SA die()s if can't create the userstate dir
Sending lib/Mail/SpamAssassin.pm
Committed revision 897946.

Was this issue the sole reason for the minimum amavis version bump?

> Was this issue the sole reason for the minimum amavis version bump?

No, this issue was not affecting amavisd-new at all. It runs with a
fixed user id, and that home directory receives the .spamassassin
directory and temporary SA files.

If you are referring to the amavisd-new version bump between 2.6.1
and 2.6.2 (associated with SpamAssassin), it was due to a change in
SA to read mail from a glob by chunks, instead of a less efficient
line-by-line. As amavisd provides a fake glob (tie), I needed to
implement the read method, in addition to getline.