[Bug 161785] spamassassin restart fails - functions bug?
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: spamassassin restart fails - functions bug?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161785
menscher+rh(a)uiuc.edu changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |menscher+rh(a)uiuc.edu
------- Additional Comments From menscher+rh(a)uiuc.edu 2006-03-17 13:42 EST -------
I'm not so sure this is "fixed" in RHEL4U3. We recently ran up2date on our
RHEL4 system, to bring it up to U3. As part of the upgrade, we got a new
version of spamassassin:
spamassassin-3.0.5-3.el4 Thu 16 Mar 2006 05:34:40 PM CST
The install of other packages lasted until 05:49:10 PM, and then up2date
restarted all the daemons. But our boot.log indicates spamd didn't restart
properly:
Mar 16 17:51:43 zeus spamassassin: spamd shutdown succeeded
Mar 16 17:51:44 zeus spamd: Could not create INET socket on 127.0.0.1:783:
Address already in use (IO::Socket::INET: Address already in use)
Mar 16 17:51:44 zeus spamassassin: spamd startup failed
The result was that everything worked fine for an hour, until the last child
exited due to the default --max-conn-per-child=200. And then we got the mess of
Mar 16 18:46:30 zeus spamc[20565]: connect(AF_INET) to spamd at 127.0.0.1
failed, retrying (#1 of 3): Connection refused
At the time, ps output indicated no spamd processes running, and a
'/etc/init.d/spamassassin restart' worked fine to fix it.
I'm assuming that the restart would have used the newly-installed init script,
so that suggests that this fix was incomplete. Or does the fix only work if
spamd was started using it (due to treatment of a pid file)?
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
18 years
[Bug 174984] New: missing timezone variable for Asia/Yekaterinburg in /usr/lib/perl5/vendor_perl/5.8.6/Date/Manip.pm
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174984
Summary: missing timezone variable for Asia/Yekaterinburg in
/usr/lib/perl5/vendor_perl/5.8.6/Date/Manip.pm
Product: Fedora Core
Version: fc4
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl-DateManip
AssignedTo: wtogami(a)redhat.com
ReportedBy: slain(a)surw.ru
CC: fedora-perl-devel-list(a)redhat.com
>From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7
Description of problem:
Programs using Date::Manip doesn't work
if timezone is set to Asia/Ekaterinburg(YEKT),cause of missing timezone variable in /usr/lib/perl5/vendor_perl/5.8.6/Date/Manip.pm
Version-Release number of selected component (if applicable):
perl-DateManip-5.42a-4
How reproducible:
Always
Steps to Reproduce:
1. sudo logwatch
Actual Results: ERROR: Date::Manip unable to determine TimeZone.
at /usr/lib/perl5/vendor_perl/5.8.6/Date/Manip.pm line 3495
Date::Manip::Date_TimeZone called at /usr/lib/perl5/vendor_perl/5.8.6/Date/Manip.pm line 661
Date::Manip::Date_Init() called at /usr/lib/perl5/vendor_perl/5.8.6/Date/Manip.pm line 779
Date::Manip::ParseDateString('epoch 1133701851') called at /usr/share/logwatch/lib/Logwatch.pm line 508
Logwatch::TimeBuild() called at /usr/sbin/logwatch line 663
Expected Results: working logwatch
Additional info:
Here is patch to solve it:
--- /usr/lib/perl5/vendor_perl/5.8.6/Date/Manip.pm 2003-07-02 22:42:47.000000000 +0600
+++ Manip.pm 2005-12-05 17:57:34.000000000 +0500
@@ -606,6 +606,7 @@
"zp4 +0400 ". # USSR Zone 3
"msd +0400 ". # Moscow Daylight
"zp5 +0500 ". # USSR Zone 4
+ "yekt +0500 ". # Asia/Yekaterinburg
"ist +0530 ". # Indian Standard
"zp6 +0600 ". # USSR Zone 5
"novst +0600 ". # Novosibirsk time zone, Russia
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
18 years
[Bug 109798] perl inline module generates broken C code
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: perl inline module generates broken C code
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109798
------- Additional Comments From jvdias(a)redhat.com 2006-03-15 18:35 EST -------
Well, this is actually because in perl-5.8.x, the <<EOF 'here-doc' quote-like
operator does interpolation by default, just like the "" or qq operator;
ie. the \n in "My string: %s\n" is changed into a literal new line character
in the Inline C source .
To turn off interpolation in the here-doc, instead of :
use Inline C => <<EOT;
do:
use Inline C => <<'EOT';
With that modification, your testcase.pl program works fine on FC-4, FC-5,
RHEL-3, and RHEL-4.
I think the reason it worked with perl-5.8.0 in RHL-9, is that interpolation
of here-document strings was broken (perhaps by UTF-8-ness) whereas now it
works as intended.
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
18 years
[Bug 183553] New: perlbug #38657: Using import() with arguments with -d: broke in 5.8.8, was okay in 5.8.7
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183553
Summary: perlbug #38657: Using import() with arguments with -d:
broke in 5.8.8, was okay in 5.8.7
Product: Fedora Core
Version: devel
Platform: All
URL: http://rt.perl.org/rt3/index.html?q=38657
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl
AssignedTo: jvdias(a)redhat.com
ReportedBy: jvdias(a)redhat.com
QAContact: dkl(a)redhat.com
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
Copied from perlbug #38657: http://rt.perl.org/rt3/index.html?q=38657 :
Using import() with arguments with -d: broke in 5.8.8, was okay in 5.8.7.
$ mkdir -p lib/Devel
$ echo 'package Devel::Foo; sub import { print "import(@_)" } sub
\ DB::DB { } 1' > lib/Devel/Foo.pm
$ /tmp/jhi/p587/bin/perl -wIlib -d:Foo -le 1
import(Devel::Foo)
$ /tmp/jhi/p588/bin/perl -wIlib -d:Foo -le 1
import(Devel::Foo)
$ /tmp/jhi/p587/bin/perl -wIlib -d:Foo=bar -le 1
import(Devel::Foo bar)
$ /tmp/jhi/p588/bin/perl -wIlib -d:Foo=bar -le 1
Can't find string terminator ";" anywhere before EOF.
$
Version-Release number of selected component (if applicable):
perl-5.8.8
How reproducible:
100%
Steps to Reproduce:
See above
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
18 years
[Bug 185542] New: perlbug #38657: Using import() with arguments with -d: broke in 5.8.8, was okay in 5.8.7
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185542
Summary: perlbug #38657: Using import() with arguments with -d:
broke in 5.8.8, was okay in 5.8.7
Product: Red Hat Certified Stacks
Version: LAMPv1
Platform: All
URL: http://rt.perl.org/rt3/index.html?q=38657
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl
AssignedTo: jvdias(a)redhat.com
ReportedBy: jvdias(a)redhat.com
QAContact: dkl(a)redhat.com
CC: fedora-perl-devel-list@redhat.com,wtogami(a)redhat.com
+++ This bug was initially created as a clone of Bug #183553 +++
Description of problem:
Copied from perlbug #38657: http://rt.perl.org/rt3/index.html?q=38657 :
Using import() with arguments with -d: broke in 5.8.8, was okay in 5.8.7.
$ mkdir -p lib/Devel
$ echo 'package Devel::Foo; sub import { print "import(@_)" } sub
\ DB::DB { } 1' > lib/Devel/Foo.pm
$ /tmp/jhi/p587/bin/perl -wIlib -d:Foo -le 1
import(Devel::Foo)
$ /tmp/jhi/p588/bin/perl -wIlib -d:Foo -le 1
import(Devel::Foo)
$ /tmp/jhi/p587/bin/perl -wIlib -d:Foo=bar -le 1
import(Devel::Foo bar)
$ /tmp/jhi/p588/bin/perl -wIlib -d:Foo=bar -le 1
Can't find string terminator ";" anywhere before EOF.
$
Version-Release number of selected component (if applicable):
perl-5.8.8
How reproducible:
100%
Steps to Reproduce:
See above
-- Additional comment from jvdias(a)redhat.com on 2006-03-01 16:53 EST --
I have reproduced this problem, and confirmed the code above used to work on
perl-5.8.6 . Suggested fix:
---
From: "Rafael Garcia-Suarez" <rgarciasuarez(a)gmail.com>
To: perl5-porters(a)perl.org
Date: 2006-03-01 16:16
On 3/1/06, via RT jhi @ ugli. hut. fi <perlbug-followup(a)perl.org> wrote:
> $ /tmp/jhi/p587/bin/perl -wIlib -d:Foo=bar -le 1
> import(Devel::Foo bar)
> $ /tmp/jhi/p588/bin/perl -wIlib -d:Foo=bar -le 1
> Can't find string terminator ";" anywhere before EOF.
Bad news, guys. This patch solves it :
==== //depot/perl/perl.c#736 - /home/rafael/p4blead/perl.c ====
--- /home/rafael/tmp/tmp.9616.0 2006-03-01 22:18:07.000000000 +0100
+++ /home/rafael/p4blead/perl.c 2006-03-01 22:18:04.000000000 +0100
@@ -3031,7 +3031,7 @@ Perl_moreswitches(pTHX_ char *s)
sv_catpv(sv, start);
else {
sv_catpvn(sv, start, s-start);
- Perl_sv_catpvf(aTHX_ sv, " split(/,/,q%c%s%c)", 0, ++s, 0);
+ Perl_sv_catpvf(aTHX_ sv, " split(/,/,q(%s))", ++s);
}
s += strlen(s);
my_setenv("PERL5DB", SvPV_nolen_const(sv));
That means that using \0 as a q() delimiter no longer works.
---
Now testing this.
-- Additional comment from jvdias(a)redhat.com on 2006-03-01 17:08 EST --
Actually, the above fix was for bleadperl; I think it's probably better to revert
to 5.8.7's code for the above, which was:
---
/* We now allow -d:Module=Foo,Bar */
while(isALNUM(*s) || *s==':') ++s;
if (*s != '=')
sv_catpv(sv, start);
else {
sv_catpvn(sv, start, s-start);
sv_catpv(sv, " split(/,/,q{");
sv_catpv(sv, ++s);
sv_catpv(sv, "})");
}
---
-- Additional comment from rgarciasuarez(a)mandriva.com on 2006-03-01 17:11 EST --
Hold on guys, the patch I posted on P5P is just here to demonstrate the cause of
the problem, not to be applied. q\0foo\0 ought to be equivalent to 'foo'. It was
working in previous perls. Still looking for a proper fix (sorry for haven't
been clear enough)
-- Additional comment from jvdias(a)redhat.com on 2006-03-01 17:21 EST --
Yes, I noticed that - I'm not applying anything yet - I'm also still investigating
- many thanks, Rafael
-- Additional comment from jvdias(a)redhat.com on 2006-03-01 18:07 EST --
Actually, under perl-5.8.0, perl-5.8.5, perl-5.8.6, and perl-5.8.7,
'q\0foo\0' does NOT work (I have tested all versions) - I get the
same result :
$ perl -e '$s=q\0foo\0;'
Number found where operator expected at -e line 1, near "q\0foo\0"
syntax error at -e line 1, near "q\0foo\0"
Execution of -e aborted due to compilation errors.
This is because '\' is a legal delimiter for q(), and the parse breaks
on the last '0;' .
$ perl -e '$s=q\0foo\; print $s,"\n";'
0foo
But if I actually create a file with 'q{0x0}foo{0x0}', it DOES work OK on all
versions:
$ cat tq.pl
#!/usr/bin/perl
$s=q0foo0;
print "$s\n";
$ ./tq.pl
q0foo0
$ tr '0' '\0' < tq.pl > tq0.pl
$ od -c tq0.pl
0000000 # ! / u s r / b i n / p e r l \n
0000020 $ s = q \0 f o o \0 ; \n p r i n t
0000040 " $ s \ n " ; \n
0000051
$ ./tq0.pl
foo
So q\0foo\0 with real, unescaped 0x0 chars DOES work OK on all versions .
I think it is just that 0x0 is a bad choice for a '%c' in Perl_sv_catpvf, as
it terminates the C string, and the interpreter doesn't get the rest of the
expression . So I think the first fix posted is OK .
If we really must make Perl_sv_catpvf handle 0x0 chars OK in expressions,
that is a different problem - I think it is debatable whether it is a problem
worth fixing.
-- Additional comment from rgarciasuarez(a)mandriva.com on 2006-03-01 18:14 EST --
Actually it works, yes, but due to shell quoting, you need to be clever :
$ perl -le 'print eval "q\0foo\0"'
foo
and that was what I meant.
The problem was with the setenv, a bit later, because setenv expects
\0-terminated strings. Fixed upstream now. Looks like my first patch was correct
after all :)
-- Additional comment from jvdias(a)redhat.com on 2006-03-01 18:47 EST --
fixed with perl-5.8.8-4, now in rawhide
-- Additional comment from wtogami(a)redhat.com on 2006-03-01 22:22 EST --
No, now it is in rawhide (moving now). I'm guessing that Jason has been very
careful about testing this change like many previous changes that I've seen him
do. Great work Jason.
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
18 years