You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2010/03/16 20:57:13 UTC
[Bug 6380] New: sa-update should handle case where some channel(s)
fail but others work
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6380
Summary: sa-update should handle case where some channel(s)
fail but others work
Product: Spamassassin
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P5
Component: sa-update
AssignedTo: dev@spamassassin.apache.org
ReportedBy: jason@i6ix.com
The case exists when using multiple channels where some update successfully but
one or more others don't (sought as of recent). Many people have written
scripts around sa-update to process exit codes and decide if sa-compile should
run. Perhaps a new exit code should be added to reflect the case described
above so that an error can be reported, but we still run sa-compile.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6380] sa-update should handle case where some channel(s) fail
but others work
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6380
--- Comment #1 from Jason Bertoch <ja...@i6ix.com> 2010-10-14 14:23:05 UTC ---
Created an attachment (id=4813)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4813)
Introduce new exit code
Introduce exit code 3 for case where at least one update channel succeeds while
at least one other did not. The new exit code will allow wrapper scripts to
run sa-compile even if a channel fails.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Re: [Bug 6380] [review] sa-update should handle case where some channel(s)
fail but others work
Posted by Jason Bertoch <ja...@i6ix.com>.
On 2010/10/27 11:27 PM, Daryl C. W. O'Shea wrote:
> I can't access this bug for some reason. I get an "undef error - Can't
> locate Class/Singleton.pm" error.
>
> Any who... do we care about having error codes corresponding to binary
> bits (the original codes were 0 1 2 4)? Should the new error code be 8?
>
I considered that in my original patch, but chose exit code 3 due to
existing logic in sub channel_failed: if ($exit > 4) { $exit++; }.
Changing this would break backward compatibility with existing wrapper
scripts.
--
/Jason
Re: [Bug 6380] [review] sa-update should handle case where some channel(s)
fail but others work
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 10/27/2010 11:27 PM, Daryl C. W. O'Shea wrote:
> I can't access this bug for some reason. I get an "undef error -
> Can't locate Class/Singleton.pm" error.
>
> Any who... do we care about having error codes corresponding to binary
> bits (the original codes were 0 1 2 4)? Should the new error code be 8?
>
> Daryl
I think it is a good idea to use binary bits because then if we need, we
can error with 12 and that's bitwise errors of both 4 & 8, etc. should
we decide to in the future.
I can't test this because I don't use multiple channels but should be
add a test case?
Regards,
KAM
Re: [Bug 6380] [review] sa-update should handle case where some channel(s)
fail but others work
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
I can't access this bug for some reason. I get an "undef error - Can't
locate Class/Singleton.pm" error.
Any who... do we care about having error codes corresponding to binary
bits (the original codes were 0 1 2 4)? Should the new error code be 8?
Daryl
[Bug 6380] [review] sa-update should handle case where some
channel(s) fail but others work
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6380
Mark Martinec <Ma...@ijs.si> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|Undefined |3.4.0
Summary|sa-update should handle |[review] sa-update should
|case where some channel(s) |handle case where some
|fail but others work |channel(s) fail but others
| |work
Status Whiteboard| |needs 2 votes for 3.4.0
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6380] [review] sa-update should handle case where some
channel(s) fail but others work
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6380
Mark Martinec <Ma...@ijs.si> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #6 from Mark Martinec <Ma...@ijs.si> 2011-09-23 16:16:57 UTC ---
closing, the current trunk (3.4) solution has been in use for one year
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6380] [review] sa-update should handle case where some
channel(s) fail but others work
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6380
--- Comment #5 from Mark Martinec <Ma...@ijs.si> 2010-10-28 12:35:41 UTC ---
Daryl writes:
> I can't access this bug for some reason. I get an "undef error - Can't
> locate Class/Singleton.pm" error.
>
> Any who... do we care about having error codes corresponding to binary
> bits (the original codes were 0 1 2 4)? Should the new error code be 8?
Kevin writes:
> I think it is a good idea to use binary bits because then if we need, we
> can error with 12 and that's bitwise errors of both 4 & 8, etc. should
> we decide to in the future.
> I can't test this because I don't use multiple channels but should be
> add a test case?
Should the new error code be 8? Perhaps. The docs and the code in sub
channel_failed implied that codes above 4 could be just an error count
(5,6,7,...), although apparently the counting in channel_failed() was
implemented incorrectly so it would never start counting errors, so
it seems there is no compatibility issue one way or another.
The Jasons's choice of 3 made use of the only free value complying
with the docs and not breaking compatibility.
A bitwise semantics of an error code would only make sense if combinations
of bit flags can actually occur and make sense. If more than one bit
can never turn on in practice, there is no value in assigning bits to
errors.
Let's see what are the possible outcomes currently:
A. no errors, no updates
B. no errors, some updates
C. some errors, no updates
D. some errors, some updates
E. lint errors, updates available but not applied
F. some other exit code as reported by import_gpg_key or GetOpt
Before assigning values, let's see what are sensible plans of action:
A. none
B. sa-compile
C. warn
D. sa-compile, warn
E. alert
F. alert
or inverted:
sa-compile if B or D
warn if C or D (or E or F)
alert if E or F
An additional constraint is that when everything is normal
the exit code should be zero!
Here is one attempt of assigning bits:
bit 0: not some updates
bit 1: some errors or lint errors or other errors
bit 2: fatal errors like lint/gpg/GetOpt failures
So:
if bit 0 is zero, run sa-compile
if bit 1 is one, log a warning
if bit 2 is one, log an alert
curr proposal
---- -----
1 001=1 A. no errors, no updates
0 000=0 B. no errors, some updates
4 011=3 C. some errors, no updates
3 010=2 D. some errors, some updates
2 111=7 E. lint errors, updates available but not applied
? x111=7+ F. some other exit code as reported by import_gpg_key or GetOpt
In the end - I don't know what would be the most sensible choice.
Current error codes never appear in combinations. Assigning sensible
semantics to each bit may require reshuffling values, which breaks
compatibility.
Thoughts?
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6380] sa-update should handle case where some channel(s) fail
but others work
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6380
--- Comment #3 from Mark Martinec <Ma...@ijs.si> 2010-10-27 12:58:28 UTC ---
I chose a slightly different approach, intending to be a bit less fragile
and perhaps easier to read.
Bug 6380: sa-update should handle case where some channel(s) fail
but others work - introduce exit status 3"
Sending sa-update.raw
Committed revision 1028033.
Will attach the diff.
Here are some test results to demonstrate the behaviour,
the only change is an added status 3, split from the 4:
# sa-update -v; echo $?
Update available for channel updates.spamassassin.org
Update was available, and was downloaded and installed successfully
0
# sa-update -v; echo $?
Update finished, no fresh updates were available
1
# sa-update -v; echo $?
Update available for channel updates.spamassassin.org
config: failed to parse line, skipping, in ...
Lint of site pre files failed, cannot continue
Update failed, exiting with code 2
2
# sa-update -v --channel updates.spamassassin.org --channel xxx.rules.yerp.org;
echo $?
Update available for channel updates.spamassassin.org
channel: no 'mirrors.xxx.rules.yerp.org' record found, channel failed
Update of at least one channel finished, other updates failed
3
# sa-update -v --channel xxx.spamassassin.org; echo $?
channel: no 'mirrors.xxx.spamassassin.org' record found, channel failed
Update failed, exiting with code 4
4
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6380] sa-update should handle case where some channel(s) fail
but others work
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6380
Mark Martinec <Ma...@ijs.si> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #4813|0 |1
is obsolete| |
Attachment #4814|0 |1
is obsolete| |
--- Comment #4 from Mark Martinec <Ma...@ijs.si> 2010-10-27 13:00:24 UTC ---
Created an attachment (id=4817)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4817)
my proposed patch
the r1028033 diff
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6380] sa-update should handle case where some channel(s) fail
but others work
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6380
--- Comment #2 from Jason Bertoch <ja...@i6ix.com> 2010-10-14 14:36:01 UTC ---
Created an attachment (id=4814)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4814)
Patch against svn
Sorry, the first patch was against the 3.3.1 release, but the svn version is
slightly different. The new patch is against the current svn trunk.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.