Hi,
I'm about to install a new Webwork server (new hardware) and I'm not sure which Linux OS and Webwork versions to use.
The system we used last term was Ubuntu 12.04 (daily updates) + Webwork 2.7 (updates from git master branch last done during Christmas'13 break). All apparently worked fine. With the end of the term I pulled updates and Webwork turned into 2.8. Logging into several random courses gives quite a few errors of several kinds. Presumably these can be fixed, but my question would be whether there is a stable/recommended Linux + Webwork combination to use (planning for fall term).
Stay with Ubuntu 12.04 + Webwork somehow pinned to 2.7?
12.04 + Webwork from git master branch?
14.04 + Webwork from git master? (meaning Apache 2.4!)
I can use Debian instead of Ubuntu, if that helps.
Thanks for any suggestions.
I suspect that if you go to the admin page on your new WeBWorK, choose the upgrade tab and upgrade your courses then the errors you see will go away. They are probably mostly due to fields that were added to the database to support new features. (Incidentally upgrading the courses will still allow them to be backward compatible with earlier versions of webwork. Extra fields produce warning messages when viewed from the admin page just to make you aware that they are present, but they don't present any problem during actual use of the course.
The other type of error you might see would be ones about missing CPAN modules. You can run webwork2/bin/check_modules.pl to see what might be missing and update your cpan modules using
sudo cpan newcpanmodule
Ubuntu works fine but so does Debian. Both of them are well supported.
Incidentally if you keep synced with master you will now be at release/2.9 which is very stable (I've used it for over half a year) and has a few new features. Release/2.9 will support Apache 2.4 although you will have to set up the configuration for the new version of apache in webwork.apache2.4-config
See http://webwork.maa.org/wiki/Release_notes_for_WeBWorK_2.9
and http://webworkgoehle.blogspot.com/ for more information.
-- Mike
Yes, there were upgrades to database tables after 2.7->2.8, but errors only went away after upgrading to 2.9 (git pull, then some more database upgrades). Ubuntu 12.04 and WW2.9 are working fine.
On a fresh minimal Ubuntu 14.04 I used ww_install.
Installation following instructions at
https://github.com/aubreyja/ww_install
went fine. Archived courses from the previous term unarchived fine (some needed database upgrades). A few caveats:
1. To be able to produce PDF hardcopies, the following Ubuntu packages needed to be installed in addition to what ww_install does:
texlive-generic-recommended (adds epsf.sty)
texlive-fonts-recommended
2. I usually configure Apache with 'ServerTokens Prod'. This shows the least possible info and doesn't work with WW2.9 when it checks Apache version. The following error occurs:
Installation following instructions at
https://github.com/aubreyja/ww_install
went fine. Archived courses from the previous term unarchived fine (some needed database upgrades). A few caveats:
1. To be able to produce PDF hardcopies, the following Ubuntu packages needed to be installed in addition to what ww_install does:
texlive-generic-recommended (adds epsf.sty)
texlive-fonts-recommended
2. I usually configure Apache with 'ServerTokens Prod'. This shows the least possible info and doesn't work with WW2.9 when it checks Apache version. The following error occurs:
Warning messages
Use of uninitialized value in subroutine entry at /opt/webwork/webwork2/lib/WeBWorK/Authen.pm line 913.<br />
Error messages
Invalid version format (version required) at /opt/webwork/webwork2/lib/WeBWorK/Authen.pm line 913.
install_webwork.sh and ww_install.pl seem to be "hard-wired" to use the ww3 branch. After installation I tried to switch to release/2.9 by
git checkout release/2.9
for both webwork2 and pg. Subsequent git pull is fine for pg, however in webwork2 it results in:
root@webwork:/opt/webwork/webwork2# git pull
Your configuration specifies to merge with the ref 'release/2.9'
from the remote, but no such ref was fetched.
What's worse, WW problems refuse to render, producing:
Are there plans to maintain something like "stable 2.9 with fixes" and if so, how does one track it via git? I would prefer to use a stable/frozen version for the next academic year of 2014-15 and not sure if that would mean 2.9 or should we be planning for v.3?
Thanks!
git checkout release/2.9
for both webwork2 and pg. Subsequent git pull is fine for pg, however in webwork2 it results in:
root@webwork:/opt/webwork/webwork2# git pull
Your configuration specifies to merge with the ref 'release/2.9'
from the remote, but no such ref was fetched.
What's worse, WW problems refuse to render, producing:
Warning messages
Error messages
Undefined subroutine &WeBWorK::PG::Translator::fileFromPath called at /opt/webwork/pg/lib/WeBWorK/PG/Translator.pm line 543.
Call stack
The information below can help locate the source of the problem.
in WeBWorK::PG::Local::new called at line 49 of /opt/webwork/webwork2/lib/WeBWorK/PG.pmin WeBWorK::PG::new called at line 663 of /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/Problem.pmin WeBWorK::ContentGenerator::Problem::pre_header_initialize called at line 183 of /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator.pmin WeBWorK::ContentGenerator::go called at line 370 of /opt/webwork/webwork2/lib/WeBWorK.pm
Are there plans to maintain something like "stable 2.9 with fixes" and if so, how does one track it via git? I would prefer to use a stable/frozen version for the next academic year of 2014-15 and not sure if that would mean 2.9 or should we be planning for v.3?
Thanks!
release/2.9 has been merged into master (that's why the error message).
Probably the simplest thing is simply to type
git checkout master
and then type
git pull
or
git pull origin
You should then get exactly what you have at the moment plus you will be connected to incremental upgrades and bug fixes as they are applied to master.
if you want to freeze things entirely you can tie your software to the 2.9
tag on the master branch so that you don't get the updates.
git tag -l # let's you see all the tag names
git checkout <tag_name> # checks out the version of master frozen at that tag.For a pretty picture of the software development look at:
We don't keep release branches around once we are done with them. (The proliferation of release branches was causing confusion. Since many people are now working on the project there was often uncertainty as to which release branches had received which updates and keeping them in sync was becoming a royal headache. ) There are now two permanent branches -- master -- which changes very slowly except for hotfixes and merging with new releases, and -- develop -- which receives all new features and improvements once we agree that they are fairly stable.
Those who like operating with the latest features can comfortably use develop -- on the whole it is fairly stable and it's not hard to retreat if an issue arises.
From time to time a release branch is split off from develop with a collection of new features and then, after a (relatively short) testing period, the release branch is merged into master and deleted.
For ww3 we have made an exception -- since that instructor interface and the software mechanisms behind it are drastically different. (ww3 uses AJAX methods extensively for immediate updates.)
We are keeping ww3 around as a separate branch rather than merging the AJAX features into develop. ww3 is already usable for those who revel in reporting bugs and working around small glitches (Peter Staab has used it for over a year in his classes), but it probably won't be ready for everyone's use until the 2015-2016 academic year. At the moment it's only the instructor interface that has changed dramatically. The student interface for ww3 is still essentially unchanged so only the instructor is dealing with new issues.
Thanks for the explanation.
I did 'git checkout master' in both pg/ and webwork2/
Seem to be tracking master:
root@webwork:/opt/webwork/webwork2# git branch -vv
* master 1d47656 [origin/master] Merge pull request #405 from openwebwork/release/2.9
release/2.9 b8035fd [origin/release/2.9] Final version number tweak
ww3 ea38288 [origin/ww3] Merge branch 'develop' of https://github.com/openwebwork/webwork2 into ww3
root@webwork:/opt/webwork/pg# git branch -vv
* master 3a2a8cc [origin/master] Merge pull request #121 from openwebwork/release/2.9
release/2.9 18f8e51 [origin/release/2.9] Merge pull request #132 from goehle/newreadme
git pull, git pull origin reports 'Already up-to-date.'
check_modules.pl apache2 doesn't find anything missing.
No upgradeable courses in Course Admin.
I'm still getting the error, whenever problem has to be viewed, either in existing sets or in Library Browser, bot in imported (i.e. unarchived) and a newly created test course based on modelCourse:
Would there be any other hints on how to fix this? Complete reinstall?
Thanks!
I did 'git checkout master' in both pg/ and webwork2/
Seem to be tracking master:
root@webwork:/opt/webwork/webwork2# git branch -vv
* master 1d47656 [origin/master] Merge pull request #405 from openwebwork/release/2.9
release/2.9 b8035fd [origin/release/2.9] Final version number tweak
ww3 ea38288 [origin/ww3] Merge branch 'develop' of https://github.com/openwebwork/webwork2 into ww3
root@webwork:/opt/webwork/pg# git branch -vv
* master 3a2a8cc [origin/master] Merge pull request #121 from openwebwork/release/2.9
release/2.9 18f8e51 [origin/release/2.9] Merge pull request #132 from goehle/newreadme
git pull, git pull origin reports 'Already up-to-date.'
check_modules.pl apache2 doesn't find anything missing.
No upgradeable courses in Course Admin.
I'm still getting the error, whenever problem has to be viewed, either in existing sets or in Library Browser, bot in imported (i.e. unarchived) and a newly created test course based on modelCourse:
Mon Jun 30 11:52:33 2014
Warning messages
Error messages
Undefined subroutine &WeBWorK::PG::Translator::fileFromPath called at /opt/webwork/pg/lib/WeBWorK/PG/Translator.pm line 543.
Call stack
The information below can help locate the source of the problem.
in WeBWorK::PG::Local::new called at line 49 of /opt/webwork/webwork2/lib/WeBWorK/PG.pmin WeBWorK::PG::new called at line 311 of /opt/webwork/webwork2/lib/WeBWorK/Utils/Tasks.pmin WeBWorK::Utils::Tasks::renderProblems called at line 1590 of /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/Instructor/SetMaker.pmin WeBWorK::ContentGenerator::Instructor::SetMaker::body called at line 155 of /opt/webwork/webwork2/lib/WeBWorK/Template.pmin WeBWorK::Template::template called at line 530 of /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator.pmin WeBWorK::ContentGenerator::content called at line 202 of /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator.pmin WeBWorK::ContentGenerator::go called at line 370 of /opt/webwork/webwork2/lib/WeBWorK.pm
Would there be any other hints on how to fix this? Complete reinstall?
Thanks!
Try changing line 543 in /opt/webwork/pg/lib/WeBWorK/PG/Translator.pm to call WeBWorK::PG::IO::fileFromPath instead of just fileFromPath. It looks like that is where it is defined. Perhaps that will do it.
Davide might have the right culprit, but in that case I'm surprised that more of us aren't seeing the error. I'm wondering if your webwork2 software is finding the correct location for the pg side of the software. This could result from misconfiguration, possibly in the site.conf file. (the reference to global.conf below is a bug -- that info is obsolete.)
When you start apache with WeBWorK installed you get a print out of a bunch of the initialization constants that WeBWorK has obtained -- make sure that all the directory addresses and urls look reasonable.
You should also see little version numbers for webwork2, pg (and the theme) at the bottom of most webwork pages.
Performing a graceful restart
webwork.apache2-config: WeBWorK server is starting
webwork.apache2-config: WeBWorK root directory set to /opt/webwork/webwork2 in webwork2/conf/webwork.apache2-config
webwork.apache2-config: The following locations and urls are set in webwork2/conf/global.conf
webwork.apache2-config: PG root directory set to /opt/webwork/pg
webwork.apache2-config: WeBWorK server userID is wwhttpd
webwork.apache2-config: WeBWorK server groupID is wwdata
webwork.apache2-config: The webwork url on this site is https://hosted2.webwork.rochester.edu/webwork2
Localize.pm: Full path for the localization directory set to |/opt/webwork/webwork2/lib/WeBWorK/Localize|
WebworkSOAP::WSDL: webwork_directory set to /opt/webwork/webwork2 via $WeBWorK::Constants::WEBWORK_DIRECTORY set in webwork.apache2-config
WebworkSOAP::WSDL: rpc_url set to https://hosted2.webwork.rochester.edu/webwork2_rpc
WebworkWebservice: webwork_directory set to /opt/webwork/webwork2 via $WeBWorK::Constants::WEBWORK_DIRECTORY set in webwork.apache2-config
Hope this helps.
-- Mike
Actually your error information seems to indicate that you have found at least one file in the pg section -- so my suggestion above won't help much.
What version of perl are you running? fileFromPath is supposed to be exported from the IO.pm file but that might not be working automatically in newer versions of perl. Davide's fix will work in that case.
I changed line 543 in Translator.pm as suggested by Davide,
fileFromPath to WeBWorK::PG::IO::fileFromPath
and the error is gone, math expressions and problems render fine. After some testing I reverted the change back to the original, i.e.
WeBWorK::PG::IO::fileFromPath back to fileFromPath
and all is still fine after some more testing. Apache restarted after any changes. Here is the output while starting Apache 2.4:
# service apache2 restart
* Restarting web server apache2 webwork.apache2-config: WeBWorK server is starting
webwork.apache2-config: WeBWorK root directory set to /opt/webwork/webwork2 in webwork2/conf/webwork.apache2-config
webwork.apache2-config: The following locations and urls are set in webwork2/conf/site.conf
webwork.apache2-config: PG root directory set to /opt/webwork/pg
webwork.apache2-config: WeBWorK server userID is www-data
webwork.apache2-config: WeBWorK server groupID is www-data
webwork.apache2-config: The webwork url on this site is https://webwork.dartmouth.edu/webwork2
Localize.pm: Full path for the localization directory set to |/opt/webwork/webwork2/lib/WeBWorK/Localize|
WebworkSOAP::WSDL: webwork_directory set to /opt/webwork/webwork2 via $WeBWorK::Constants::WEBWORK_DIRECTORY set in webwork.apache2-config
WebworkSOAP::WSDL: rpc_url set to https://webwork.dartmouth.edu/webwork2_rpc
WebworkWebservice: webwork_directory set to /opt/webwork/webwork2 via $WeBWorK::Constants::WEBWORK_DIRECTORY set in webwork.apache2-config
The only changes to site.conf are for smtpServer and smptSender (except for those introduced from ww_install.pl prompt inputs).
/etc/perl
/usr/local/lib/perl/5.18.2
/usr/local/share/perl/5.18.2
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.18
/usr/share/perl/5.18
/usr/local/lib/site_perl
.
There are quite some Perl packages in /usr/local/, and I understand those were installed from CPAN by install_prerequisites.sh. I haven't installed or upgraded anything from CPAN. 'cpan' shows Bundle::WeBWorK is up to date. Though I can't see any use of Bundle::WeBWorK in ww_install scripts…
The system otherwise is a fresh 14.04 install with only the SSH service installed before running ww_install.pl.
fileFromPath to WeBWorK::PG::IO::fileFromPath
and the error is gone, math expressions and problems render fine. After some testing I reverted the change back to the original, i.e.
WeBWorK::PG::IO::fileFromPath back to fileFromPath
and all is still fine after some more testing. Apache restarted after any changes. Here is the output while starting Apache 2.4:
# service apache2 restart
* Restarting web server apache2 webwork.apache2-config: WeBWorK server is starting
webwork.apache2-config: WeBWorK root directory set to /opt/webwork/webwork2 in webwork2/conf/webwork.apache2-config
webwork.apache2-config: The following locations and urls are set in webwork2/conf/site.conf
webwork.apache2-config: PG root directory set to /opt/webwork/pg
webwork.apache2-config: WeBWorK server userID is www-data
webwork.apache2-config: WeBWorK server groupID is www-data
webwork.apache2-config: The webwork url on this site is https://webwork.dartmouth.edu/webwork2
Localize.pm: Full path for the localization directory set to |/opt/webwork/webwork2/lib/WeBWorK/Localize|
WebworkSOAP::WSDL: webwork_directory set to /opt/webwork/webwork2 via $WeBWorK::Constants::WEBWORK_DIRECTORY set in webwork.apache2-config
WebworkSOAP::WSDL: rpc_url set to https://webwork.dartmouth.edu/webwork2_rpc
WebworkWebservice: webwork_directory set to /opt/webwork/webwork2 via $WeBWorK::Constants::WEBWORK_DIRECTORY set in webwork.apache2-config
The only changes to site.conf are for smtpServer and smptSender (except for those introduced from ww_install.pl prompt inputs).
Version numbers at the bottom of Webwork webpages are:
@INC:/etc/perl
/usr/local/lib/perl/5.18.2
/usr/local/share/perl/5.18.2
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.18
/usr/share/perl/5.18
/usr/local/lib/site_perl
.
There are quite some Perl packages in /usr/local/, and I understand those were installed from CPAN by install_prerequisites.sh. I haven't installed or upgraded anything from CPAN. 'cpan' shows Bundle::WeBWorK is up to date. Though I can't see any use of Bundle::WeBWorK in ww_install scripts…
The system otherwise is a fresh 14.04 install with only the SSH service installed before running ww_install.pl.
Well, after two days of testing and seeing the correct behaviour, the error is back, without any admin actions on the server.
Error or no-error situation seems to be toggled by 'service apache2 restart'. Not every restart, but probably one in five restarts switches Webwork or Apache/mod_perl to the mode where IO.pm is not loaded?
my current suspicion is that it is loading IO.pm but the Exporter module behaves differently in perl 5.18 than in 5.8 where IO.pm was coded or 5.12 which I am using at the moment. The question is whether fileFromPath is being exported from the IO.pm module into the Translator.pm module. The original code might easily have been relying on some undocumented default behavior about what is automatically exported. And perl 5.18 has changed the undocumented behavior.
If I remember correctly the syntax:
use .....PG::IO qw(fileFromPath);
will insure that fileFromPath is exported. It could be that sometimes fileFromPath is lying around in the name space after reboot and doesn't need to be exported but sometimes it isn't.
Exporting the subroutine explicitly might stop the inconsistent behavior you are seeing. Using the fully qualified name for fileFromPath means that the subroutine doesn't even need to be exported.
Thanks for the suggestion. When I change
use WeBWorK::PG::IO;
for explicit import of 'fileFromPath':
use WeBWorK::PG::IO qw(fileFromPath);
it turns out 'fileFromPath' is not being exported by WeBWorK::PG::IO.pm:
# service apache2 restart
* Restarting web server apache2 webwork.apache2-config: WeBWorK server is starting
webwork.apache2-config: WeBWorK root directory set to /opt/webwork/webwork2 in webwork2/conf/webwork.apache2-config
webwork.apache2-config: The following locations and urls are set in webwork2/conf/site.conf
webwork.apache2-config: PG root directory set to /opt/webwork/pg
webwork.apache2-config: WeBWorK server userID is www-data
webwork.apache2-config: WeBWorK server groupID is www-data
webwork.apache2-config: The webwork url on this site is https://webwork.dartmouth.edu/webwork2
Localize.pm: Full path for the localization directory set to |/opt/webwork/webwork2/lib/WeBWorK/Localize|
AH00526: Syntax error on line 12 of /etc/apache2/conf-enabled/webwork.conf:
"fileFromPath" is not exported by the WeBWorK::PG::IO module\nCan't continue after import errors at /opt/webwork/pg/lib/WeBWorK/PG/Translator.pm line 14.\nBEGIN failed--compilation aborted at /opt/webwork/pg/lib/WeBWorK/PG/Translator.pm line 14.\nCompilation failed in require at /opt/webwork/pg/lib/WeBWorK/PG/IO.pm line 8.\nBEGIN failed--compilation aborted at /opt/webwork/pg/lib/WeBWorK/PG/IO.pm line 8.\nCompilation failed in require at /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/GatewayQuiz.pm line 35.\nBEGIN failed--compilation aborted at /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/GatewayQuiz.pm line 35.\nCompilation failed in require at /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/LoginProctor.pm line 32.\nBEGIN failed--compilation aborted at /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/LoginProctor.pm line 32.\nCompilation failed in require at (eval 524) line 2.\nBEGIN failed--compilation aborted at /opt/webwork/webwork2/lib/WeBWorK.pm line 85.\nCompilation failed in require at /opt/webwork/webwork2/lib/Apache/WeBWorK.pm line 35.\nBEGIN failed--compilation aborted at /opt/webwork/webwork2/lib/Apache/WeBWorK.pm line 35.\n
Action 'start' failed.
The Apache error log may have more information.
Nothing additional in apache logs. If I run 'apache2ctl -t' many times in a row, about half of them end up with configtest failed. The error is the above "fileFromPath" is not exported by the WeBWorK::PG::IO module.
I noticed that IO.pm has 'use WeBWorK::PG::Translator;' and then
Translator.pm has 'use WeBWorK::PG::IO;'. Commenting out the former doesn't seem to make any difference.
use WeBWorK::PG::IO;
for explicit import of 'fileFromPath':
use WeBWorK::PG::IO qw(fileFromPath);
it turns out 'fileFromPath' is not being exported by WeBWorK::PG::IO.pm:
# service apache2 restart
* Restarting web server apache2 webwork.apache2-config: WeBWorK server is starting
webwork.apache2-config: WeBWorK root directory set to /opt/webwork/webwork2 in webwork2/conf/webwork.apache2-config
webwork.apache2-config: The following locations and urls are set in webwork2/conf/site.conf
webwork.apache2-config: PG root directory set to /opt/webwork/pg
webwork.apache2-config: WeBWorK server userID is www-data
webwork.apache2-config: WeBWorK server groupID is www-data
webwork.apache2-config: The webwork url on this site is https://webwork.dartmouth.edu/webwork2
Localize.pm: Full path for the localization directory set to |/opt/webwork/webwork2/lib/WeBWorK/Localize|
AH00526: Syntax error on line 12 of /etc/apache2/conf-enabled/webwork.conf:
"fileFromPath" is not exported by the WeBWorK::PG::IO module\nCan't continue after import errors at /opt/webwork/pg/lib/WeBWorK/PG/Translator.pm line 14.\nBEGIN failed--compilation aborted at /opt/webwork/pg/lib/WeBWorK/PG/Translator.pm line 14.\nCompilation failed in require at /opt/webwork/pg/lib/WeBWorK/PG/IO.pm line 8.\nBEGIN failed--compilation aborted at /opt/webwork/pg/lib/WeBWorK/PG/IO.pm line 8.\nCompilation failed in require at /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/GatewayQuiz.pm line 35.\nBEGIN failed--compilation aborted at /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/GatewayQuiz.pm line 35.\nCompilation failed in require at /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/LoginProctor.pm line 32.\nBEGIN failed--compilation aborted at /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/LoginProctor.pm line 32.\nCompilation failed in require at (eval 524) line 2.\nBEGIN failed--compilation aborted at /opt/webwork/webwork2/lib/WeBWorK.pm line 85.\nCompilation failed in require at /opt/webwork/webwork2/lib/Apache/WeBWorK.pm line 35.\nBEGIN failed--compilation aborted at /opt/webwork/webwork2/lib/Apache/WeBWorK.pm line 35.\n
Action 'start' failed.
The Apache error log may have more information.
Nothing additional in apache logs. If I run 'apache2ctl -t' many times in a row, about half of them end up with configtest failed. The error is the above "fileFromPath" is not exported by the WeBWorK::PG::IO module.
I noticed that IO.pm has 'use WeBWorK::PG::Translator;' and then
Translator.pm has 'use WeBWorK::PG::IO;'. Commenting out the former doesn't seem to make any difference.
This seems to be the most efficient debugging technique. So far I haven't
been able to isolate the Exporter problem although as you've pointed out we can work around it in this instance by fully qualifying the fileFromPath function name.
I started a new thread on this subject:
http://webwork.maa.org/moodle/mod/forum/discuss.php?d=3406
In IO.pm I have commented out
package WeBWorK::PG::IO;
#use base qw(Exporter);
#use WeBWorK::PG::Translator;
use JSON qw(decode_json);
and added
BEGIN {
<------>require Exporter;
<------>our @EXPORT = qw(
This eliminates apache configtest errors, and I was hoping it will stabilize Apache/mod_perl, but no — fileFromPath() availability is still intermittent with Apache restarts.
package WeBWorK::PG::IO;
#use base qw(Exporter);
#use WeBWorK::PG::Translator;
use JSON qw(decode_json);
and added
BEGIN {
<------>require Exporter;
<------>our @EXPORT = qw(
This eliminates apache configtest errors, and I was hoping it will stabilize Apache/mod_perl, but no — fileFromPath() availability is still intermittent with Apache restarts.
Good idea, too bad it didn't work. fileFromPath is pretty clearly in the Export list. I don't know if the rules for Export have changed (I confess I never looked very closely at them in the first place -- what we were doing seemed to work at the time).
The fact that this works on some reboots but not others makes me want to double check that there are no rogue child processes around. Try to stop apache (not just a graceful restart) and then check that no httpd processes are running (i use "top" to check this). Then restart.
I have on rare occasions had a process that refused to die under normal restarts and then proceeded to cause errors every now and then when it was its turn to handle a request. The procedure above probably won't solve the problem but it will help reassure us that a rogue process isn't a cause.
I just ran into this too. Running Ubuntu 14.04 (Apache 2.4) and perl 5.18. It seems to differ from another machine running apache 2.2 and perl 5.12. I changed the fileFromPath to it's absolute path and it's running fine now.
Strange thing is that I'm running the develop branch and switch to the master branch with no errors.
I tried with stopping apache2, checking for processes and then starting it again, instead of just 'service apache2 restart'. It takes several seconds for all apache processes to quit, but so far I didn't run into any lingering/defunct/stuck processes. Sometimes it takes 5-6 apache restarts to toggle Webwork from working state into non-working, sometimes just one restart does it.
For this last testing I reinstalled server completely from scratch, i.e. Ubuntu server 14.04 reinstall with partition format. Minimal install with SSH, NTP, postfix, smartd and apcupsd services only. Then 'git clone https://github.com/aubreyja/ww_install.git' and ran 'sudo install_webwork.sh'. During script run there was an error 'Module apreq does not exist', but it wasn't blocking, and an apreq2 apache module exists and was enabled by ww installer. Git branch settings remain as they were set by the installer. Old courses imported fine with subsequent DB upgrades.
System is Ubuntu 14.04 with current updates, security-updates and backports.
I did not modify Translator.pm:543 with full module path for fileFromPath() so far. (What about all the other functions exported from IO.pm?)
Is there a way to configure WW to run in debug mode, such that all individual module loads are recorded?
# uname -a
Linux webwork 3.13.0-30-generic #55-Ubuntu SMP Fri Jul 4 21:40:53 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
# apt-cache policy apache2
apache2:
Installed: 2.4.7-1ubuntu4
Candidate: 2.4.7-1ubuntu4
Version table:
*** 2.4.7-1ubuntu4 0
500 http://euler:9999/ubuntu.thayer.dartmouth.edu/ trusty/main amd64 Packages
# apt-cache policy perl
perl:
Installed: 5.18.2-2ubuntu1
Candidate: 5.18.2-2ubuntu1
Version table:
*** 5.18.2-2ubuntu1 0
500 http://euler:9999/ubuntu.thayer.dartmouth.edu/ trusty/main amd64 Packages
# apt-cache policy libapache2-mod-perl2
libapache2-mod-perl2:
Installed: 2.0.8+httpd24-r1449661-6ubuntu2
Candidate: 2.0.8+httpd24-r1449661-6ubuntu2
Version table:
*** 2.0.8+httpd24-r1449661-6ubuntu2 0
500 http://euler:9999/ubuntu.thayer.dartmouth.edu/ trusty/main amd64 Packages
/opt/webwork/webwork2# git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/develop
remotes/origin/master
remotes/origin/ww3
/opt/webwork/pg# git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/develop
remotes/origin/master
For this last testing I reinstalled server completely from scratch, i.e. Ubuntu server 14.04 reinstall with partition format. Minimal install with SSH, NTP, postfix, smartd and apcupsd services only. Then 'git clone https://github.com/aubreyja/ww_install.git' and ran 'sudo install_webwork.sh'. During script run there was an error 'Module apreq does not exist', but it wasn't blocking, and an apreq2 apache module exists and was enabled by ww installer. Git branch settings remain as they were set by the installer. Old courses imported fine with subsequent DB upgrades.
System is Ubuntu 14.04 with current updates, security-updates and backports.
I did not modify Translator.pm:543 with full module path for fileFromPath() so far. (What about all the other functions exported from IO.pm?)
Is there a way to configure WW to run in debug mode, such that all individual module loads are recorded?
# uname -a
Linux webwork 3.13.0-30-generic #55-Ubuntu SMP Fri Jul 4 21:40:53 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
# apt-cache policy apache2
apache2:
Installed: 2.4.7-1ubuntu4
Candidate: 2.4.7-1ubuntu4
Version table:
*** 2.4.7-1ubuntu4 0
500 http://euler:9999/ubuntu.thayer.dartmouth.edu/ trusty/main amd64 Packages
# apt-cache policy perl
perl:
Installed: 5.18.2-2ubuntu1
Candidate: 5.18.2-2ubuntu1
Version table:
*** 5.18.2-2ubuntu1 0
500 http://euler:9999/ubuntu.thayer.dartmouth.edu/ trusty/main amd64 Packages
# apt-cache policy libapache2-mod-perl2
libapache2-mod-perl2:
Installed: 2.0.8+httpd24-r1449661-6ubuntu2
Candidate: 2.0.8+httpd24-r1449661-6ubuntu2
Version table:
*** 2.0.8+httpd24-r1449661-6ubuntu2 0
500 http://euler:9999/ubuntu.thayer.dartmouth.edu/ trusty/main amd64 Packages
/opt/webwork/webwork2# git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/develop
remotes/origin/master
remotes/origin/ww3
/opt/webwork/pg# git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/develop
remotes/origin/master
Peter Staab has a tentative fix at https://github.com/openwebwork/pg/pull/143, if you want to give it a try. Or wait until it's merged in the master.
When IO.pm and Translator.pm are replaced with their versions downloaded from
https://raw.githubusercontent.com/pstaabp/pg/hotfix/readfile/lib/WeBWorK/PG
as of July 16, the error is still there. One must restart Apache multiple times to get the error condition, which seems to occur randomly between restarts.
This is on Ubuntu 14.04 and Debian testing with updates as of today.
https://raw.githubusercontent.com/pstaabp/pg/hotfix/readfile/lib/WeBWorK/PG
as of July 16, the error is still there. One must restart Apache multiple times to get the error condition, which seems to occur randomly between restarts.
This is on Ubuntu 14.04 and Debian testing with updates as of today.
For those following this thread.
Try the following minimalist change.
In the file pg/lib/WeBWorK/PG/IO.pm
comment out the line:
our @ISA = qw(PGcore);
so that it reads:
#our @ISA = qw(PGcore);
See if this fixes the problem even when you reboot several times. (There is some kind of race condition that causes the error so it is intermittent and hard to track down. )
(I think that I introduced this line inadvertently while debugging the new askSage features. I can't see where it's needed and it might be masking access to the Exporter module.)
Let us know if this seems to work and particularly let us know if the error occasionally reoccurs after a reboot.
So far I haven't been able to reproduce the problem on my Vagrant installation where I've installed perl 5.18.0 but I'm not sure I've got the proper test environment since I think apache may still be using the perl 5.14 version.
-- Mike Gage
It turns out this doesn't solve the problem. I've started a new thread with
the IO.pm error title:
This error shows up, but not consistently if the operating system is upgraded to use perl 5.16 or higher. (The new operating system has an asynchronous loading pattern which is not allowed for in the original code.) The pull requestswebwork2: #465 and pg #148 address this issue. Both pull requests need to be applied to the develop branch at the same time since files are changed in both the webwork2 and pg directories.
After further testing these pull requests will become part of the develop release.
I just upgraded ubuntu (which upgraded perl), and I now get this error as well. Moreover, starting apache produces several warnings related to perl:
webwork.apache2-config: WeBWorK server is starting
webwork.apache2-config: WeBWorK root directory set to /opt/webwork/webwork2 in webwork2/conf/webwork.apache2-config
webwork.apache2-config: The following locations and urls are set in webwork2/conf/site.conf
webwork.apache2-config: PG root directory set to /opt/webwork/pg
webwork.apache2-config: WeBWorK server userID is www-data
webwork.apache2-config: WeBWorK server groupID is www-data
webwork.apache2-config: The webwork url on this site is http://hobbes.la.asu.edu/webwork2
Localize.pm: Full path for the localization directory set to |/opt/webwork/webwork2/lib/WeBWorK/Localize|
defined(@array) is deprecated at /usr/share/perl5/Mail/Sender.pm line 318.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /usr/share/perl5/Mail/Sender.pm line 2693.
(Maybe you should just omit the defined()?)
Smartmatch is experimental at /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/Problem.pm line 677.
Smartmatch is experimental at /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/Problem.pm line 678.
Smartmatch is experimental at /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/Problem.pm line 679.
Smartmatch is experimental at /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/Problem.pm line 680.
WebworkSOAP::WSDL: webwork_directory set to /opt/webwork/webwork2 via $WeBWorK::Constants::WEBWORK_DIRECTORY set in webwork.apache2-config
WebworkSOAP::WSDL: rpc_url set to http://hobbes.la.asu.edu/webwork2_rpc
WebworkWebservice: webwork_directory set to /opt/webwork/webwork2 via $WeBWorK::Constants::WEBWORK_DIRECTORY set in webwork.apache2-config
The Mail::Sender error is because you need to upgrade your Mail::Sender package.
I see the experimental warning when I use WeBWorK3 stuff. I used the ~~ (I think that's the smart match) and so does Problem.pm.
We just decided that the lowest perl appropriate is 5.10, which is where it was introduced and it looks like it might have changed in more-current versions, so we may need to change this until we decide on a more-current version of perl.