PacketFence - BTS - PacketFence
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001283PacketFenceerror-handlingpublic2011-09-27 03:192012-04-23 11:01
Reporterpsnizek 
Assigned Toobilodeau 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version3.0.0 
Target Version3.3.2Fixed in Version3.3.2 
fixed in git revisionf13a991d8f9cf40896520749bdb961b2413232eb
fixed in mtn revision
Summary0001283: pfcmd checkup fails anyway if perl produces warnings when checking pf/web/captiveportal_modperl_require.pl
DescriptionEnvironment: Vanilla, Slackware 13.1, perl 5.10.1, seems to be always reproducible on this Perl version.

if this command "perl -c /usr/local/pf/lib/pf/web/captiveportal_modperl_require.pl 2>&1" is executed successfully on the command line, the return value is 0 despite all Perl warnings. Because of checking captive_portal[0] for syntax OK this test will always fail if the contents of the first array space is not 'syntax OK$' but some perl warning instead. In my case the 'syntax OK$' appeard in captive_portal[64].
Rather than grepping for 'syntax OK$' would it make sense to check the return value instead?

Please see patch below. The patch may be far from perfect but this way the execution does not fail because of Perl warnings. It still does fail if 'syntax OK' is missing.

The perl warnings I had were:
Prototype mismatch: sub pf::web::LC_ALL: none vs () at /usr/local/pf/lib/pf/web.pm line 36
Prototype mismatch: sub pf::web::LC_NUMERIC: none vs () at /usr/local/pf/lib/pf/web.pm line 36
Prototype mismatch: sub pf::web::LC_TIME: none vs () at /usr/local/pf/lib/pf/web.pm line 36
Prototype mismatch: sub pf::web::LC_MONETARY: none vs () at /usr/local/pf/lib/pf/web.pm line 36
Prototype mismatch: sub pf::web::LC_CTYPE: none vs () at /usr/local/pf/lib/pf/web.pm line 36
Prototype mismatch: sub pf::web::LC_MESSAGES: none vs () at /usr/local/pf/lib/pf/web.pm line 36
Prototype mismatch: sub pf::web::LC_COLLATE: none vs () at /usr/local/pf/lib/pf/web.pm line 36
Prototype mismatch: sub pf::web::guest::LC_ALL: none vs () at /usr/local/pf/lib/pf/web/guest.pm line 35
Prototype mismatch: sub pf::web::guest::LC_NUMERIC: none vs () at /usr/local/pf/lib/pf/web/guest.pm line 35
Prototype mismatch: sub pf::web::guest::LC_TIME: none vs () at /usr/local/pf/lib/pf/web/guest.pm line 35
Prototype mismatch: sub pf::web::guest::LC_MONETARY: none vs () at /usr/local/pf/lib/pf/web/guest.pm line 35
Prototype mismatch: sub pf::web::guest::LC_CTYPE: none vs () at /usr/local/pf/lib/pf/web/guest.pm line 35
Prototype mismatch: sub pf::web::guest::LC_MESSAGES: none vs () at /usr/local/pf/lib/pf/web/guest.pm line 35
Prototype mismatch: sub pf::web::guest::LC_COLLATE: none vs () at /usr/local/pf/lib/pf/web/guest.pm line 35
Prototype mismatch: sub pf::web::util::LC_ALL: none vs () at /usr/local/pf/lib/pf/web/util.pm line 22
Prototype mismatch: sub pf::web::util::LC_NUMERIC: none vs () at /usr/local/pf/lib/pf/web/util.pm line 22
Prototype mismatch: sub pf::web::util::LC_TIME: none vs () at /usr/local/pf/lib/pf/web/util.pm line 22
Prototype mismatch: sub pf::web::util::LC_MONETARY: none vs () at /usr/local/pf/lib/pf/web/util.pm line 22
Prototype mismatch: sub pf::web::util::LC_CTYPE: none vs () at /usr/local/pf/lib/pf/web/util.pm line 22
Prototype mismatch: sub pf::web::util::LC_MESSAGES: none vs () at /usr/local/pf/lib/pf/web/util.pm line 22
Prototype mismatch: sub pf::web::util::LC_COLLATE: none vs () at /usr/local/pf/lib/pf/web/util.pm line 22
Prototype mismatch: sub pf::sms_activation::LC_ALL: none vs () at /usr/local/pf/lib/pf/sms_activation.pm line 17
Prototype mismatch: sub pf::sms_activation::LC_NUMERIC: none vs () at /usr/local/pf/lib/pf/sms_activation.pm line 17
Prototype mismatch: sub pf::sms_activation::LC_TIME: none vs () at /usr/local/pf/lib/pf/sms_activation.pm line 17
Prototype mismatch: sub pf::sms_activation::LC_MONETARY: none vs () at /usr/local/pf/lib/pf/sms_activation.pm line 17
Prototype mismatch: sub pf::sms_activation::LC_CTYPE: none vs () at /usr/local/pf/lib/pf/sms_activation.pm line 17
Prototype mismatch: sub pf::sms_activation::LC_MESSAGES: none vs () at /usr/local/pf/lib/pf/sms_activation.pm line 17
Prototype mismatch: sub pf::sms_activation::LC_COLLATE: none vs () at /usr/local/pf/lib/pf/sms_activation.pm line 17
Constant subroutine pf::web::custom::LC_CTYPE redefined at
        /usr/lib/perl5/5.10.1/Exporter.pm line 67, <DATA> line 522 (0000001)
    (S) You redefined a subroutine which had previously been
    eligible for inlining. See perlsub/"Constant Functions" for
    commentary and workarounds.

Prototype mismatch: sub pf::web::custom::LC_CTYPE () vs none at
        /usr/lib/perl5/5.10.1/Exporter.pm line 67, <DATA> line 522 (0000002)
    (S prototype) The subroutine being declared or defined had previously been
    declared or defined with a different function prototype.

Constant subroutine pf::web::custom::LC_NUMERIC redefined at
        /usr/lib/perl5/5.10.1/Exporter.pm line 67, <DATA> line 522 (0000001)
Prototype mismatch: sub pf::web::custom::LC_NUMERIC () vs none at
        /usr/lib/perl5/5.10.1/Exporter.pm line 67, <DATA> line 522 (0000002)
Constant subroutine pf::web::custom::LC_TIME redefined at
        /usr/lib/perl5/5.10.1/Exporter.pm line 67, <DATA> line 522 (0000001)
Prototype mismatch: sub pf::web::custom::LC_TIME () vs none at
        /usr/lib/perl5/5.10.1/Exporter.pm line 67, <DATA> line 522 (0000002)
Constant subroutine pf::web::custom::LC_COLLATE redefined at
        /usr/lib/perl5/5.10.1/Exporter.pm line 67, <DATA> line 522 (0000001)

According to Dr Google this seems to be a gettext problem with POSIX in Perl 5.10.x. Please see here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479803 [^]


Also, I would like to draw your attention on a minor logging issue:
2011-09-23 21:18:23 host.domain.com local5.warning packetfence Error trying to run command: perl -c /usr/local/pf/lib/pf/web/captiveportal_modperl_require.pl 2>&1 called from checkup::apache. Child exited with non-zero value 2 (pf::util::pf_run)
The syslog level "warning" contradicts to Packetfence's "Error" level.
Steps To Reproduce
Additional Information--- checkup.pm.orig 2011-09-23 19:04:15.475226653 +0200
+++ checkup.pm.new 2011-09-23 22:26:12.598194162 +0200
@@ -698,11 +698,11 @@
     }

     # Apache PerlPostConfigRequire scripts *must* compile otherwise apache startup silently fails
- my @captive_portal = pf_run("perl -c $lib_dir/pf/web/captiveportal_modperl_require.pl 2>&1");
- if ($captive_portal[0] !~ /syntax OK$/) {
- add_problem(
- $FATAL, "Apache will fail to start! $lib_dir/pf/web/captiveportal_modperl_require.pl doesn't compile"
- );
+ my $captive_portal = pf_run("perl -c $lib_dir/pf/web/captiveportal_modperl_require.pl 2>&1");
+ if ( $captive_portal !~ /syntax OK$/ ) {
+ add_problem(
+ $FATAL, "Apache will fail to start! $lib_dir/pf/web/captiveportal_modperl_require.pl doesn't compile"
+ );
     }
     my @back_end = pf_run("perl -c $lib_dir/pf/web/backend_modperl_require.pl 2>&1");
     if ($back_end[0] !~ /syntax OK$/) {
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2011-09-27 03:19psnizekNew Issue
2012-04-17 21:36obilodeauStatusnew => assigned
2012-04-17 21:36obilodeauAssigned To => obilodeau
2012-04-17 21:53obilodeaugit revision => f13a991d8f9cf40896520749bdb961b2413232eb
2012-04-17 21:53obilodeauNote Added: 0002654
2012-04-17 21:53obilodeauStatusassigned => resolved
2012-04-17 21:53obilodeauFixed in Version => +1
2012-04-17 21:53obilodeauResolutionopen => fixed
2012-04-18 09:51obilodeauTarget Version => 3.3.0
2012-04-18 09:51obilodeauFixed in Version+1 => 3.3.0
2012-04-18 10:02obilodeauNote Added: 0002661
2012-04-18 10:02obilodeauFixed in Version3.3.0 => +1
2012-04-18 10:02obilodeauTarget Version3.3.0 => +1
2012-04-23 11:00obilodeauTarget Version+1 => 3.3.2
2012-04-23 11:00obilodeauFixed in Version+1 => 3.3.2
2012-04-23 11:01obilodeauNote Added: 0002686
2012-04-23 11:01obilodeauStatusresolved => closed

Notes
(0002654)
obilodeau   
2012-04-17 21:53   
Extended your patch for both captive portal and backend. Agreed that testing exit code would have been an alternative but pf_run already does it and report it in the logs.

I reworded Error to Problem under pf_run. It is still logged at the warning level. It's up to the caller to decide if problem should be reported more aggressively. In the current case we report a fatal issue in checkup.

I applied the fix to stable so it should be part of our next release. Under what name (and optionally organization) would you like your contribution under? Right now I've put psnizek.
(0002661)
obilodeau   
2012-04-18 10:02   
fixed/target version updates. wrongly re-assigned by mistake.
(0002686)
obilodeau   
2012-04-23 11:01   
fix released in 3.3.2