Koha on Ubuntu LTS
On 7/24/2012 I wrote: [snip]
Anyway, I've just repartioned the sandbox, installed a fresh 12.04 server, and am right now wget'ting 3.6.7 More later ...
Just got back after a few days away. Installation all went well (did not install php package, but used php-pear leaving Apache2 as worker) OPAC and staff client both functional from LAN workstations. Restored a working db (3.6.1) to MySQL, Koha "did its thing" updating the db format, OPAC showed a "System Maintenance" placard, I re-indexed biblios and authorities (no problem), checked the cron-job for the incremental zebra indexing (working properly.) So everything fine except: MAJOR: OPAC is stuck with the "System Maintenance" page - I've rebooted (same result), so am looking for ideas, please, as to where to start looking. This is _not_ a browser cache problem. SEMI-MAJOR: The cron /etc/cron.d/koha (exactly as per Wiki, README, etc) only works if owner:group is root:root or root:koha (fails completely if koha:koha). This (because the "user koha" appears in field #6, and without it, it fails) is leading to the zebra incremental running twice: Jul 28 17:20:01 server2 CRON[2132]: (root) CMD (koha $KOHAPATH/bin/migration_tools/rebuild_zebra.pl -a -b -z &> /dev/null) Jul 28 17:20:01 server2 CRON[2135]: (koha) CMD ( $KOHAPATH/bin/migration_tools/rebuild_zebra.pl -a -b -z &> /dev/null) This leads to another: SEMI-MAJOR: From Koha dependencies (I think) nullmailer got installed. It is doing a serious job of bloating the mail.log and mail.err (both up to over half a Gig in a couple of hours, because each "double cron" appears to want to email: Jul 28 17:20:01 server2 CRON[2136]: (koha) MAIL (mailed 1 byte of output; but got status 0x0001, #012) Is there any way in Koha to turn off this type of mailing? Or should I look for another way of sending these things to /dev/null without logging? (I get the nasty feeling that nullmailer is attempting to recursively retry to send the whole queue *every minute* i.e. whenever another input is detected from the one minute zebra cronjob. MINOR: "Superlibrarian" permission flags (not names|passwords) got lost (so I couldn't log in until I reset them; same for two other staff members, and with no permissions even the correct password doesn't let you in.) All other "less than supers" were fine ... Looking forward to suggestions, thanks - Paul [Notes, fairly detailed, at <http://navalmarinearchive.com/research/koha_ubuntu.html>
Paul, Just got back after a few days away. Installation all went well (did not
install php package, but used php-pear leaving Apache2 as worker) OPAC and staff client both functional from LAN workstations. Restored a working db (3.6.1) to MySQL, Koha "did its thing" updating the db format, OPAC showed a "System Maintenance" placard, I re-indexed biblios and authorities (no problem), checked the cron-job for the incremental zebra indexing (working properly.)
So everything fine except:
MAJOR: OPAC is stuck with the "System Maintenance" page - I've rebooted (same result), so am looking for ideas, please, as to where to start looking. This is _not_ a browser cache problem.
Did you try rerunning updatedatabase? SEMI-MAJOR: The cron /etc/cron.d/koha (exactly as per Wiki, README, etc)
only works if owner:group is root:root or root:koha (fails completely if koha:koha). This (because the "user koha" appears in field #6, and without it, it fails) is leading to the zebra incremental running twice: Jul 28 17:20:01 server2 CRON[2132]: (root) CMD (koha $KOHAPATH/bin/migration_tools/**rebuild_zebra.pl <http://rebuild_zebra.pl>-a -b -z &> /dev/null) Jul 28 17:20:01 server2 CRON[2135]: (koha) CMD ( $KOHAPATH/bin/migration_tools/**rebuild_zebra.pl <http://rebuild_zebra.pl>-a -b -z &> /dev/null) This leads to another:
The instructions all assume a user crontab. If you are using /etc/cron.d/koha, you should not be using the user crontab (as all the instructions assume), or you could do things vice versa. SEMI-MAJOR: From Koha dependencies (I think) nullmailer got installed. It
is doing a serious job of bloating the mail.log and mail.err (both up to over half a Gig in a couple of hours, because each "double cron" appears to want to email: Jul 28 17:20:01 server2 CRON[2136]: (koha) MAIL (mailed 1 byte of output; but got status 0x0001, #012) Is there any way in Koha to turn off this type of mailing? Or should I look for another way of sending these things to /dev/null without logging? (I get the nasty feeling that nullmailer is attempting to recursively retry to send the whole queue *every minute* i.e. whenever another input is detected from the one minute zebra cronjob.
So, remove nullmailer. nullmailer needs to be configured appropriately if you are using it. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
On Sat, Jul 28, 2012 at 6:30 PM, Jared Camins-Esakov <jcamins@cpbibliography.com> wrote:
Paul,
Just got back after a few days away. Installation all went well (did not install php package, but used php-pear leaving Apache2 as worker) OPAC and staff client both functional from LAN workstations. Restored a working db (3.6.1) to MySQL, Koha "did its thing" updating the db format, OPAC showed a "System Maintenance" placard, I re-indexed biblios and authorities (no problem), checked the cron-job for the incremental zebra indexing (working properly.)
So everything fine except:
MAJOR: OPAC is stuck with the "System Maintenance" page - I've rebooted (same result), so am looking for ideas, please, as to where to start looking. This is _not_ a browser cache problem.
Did you try rerunning updatedatabase?
Also double check to be sure that OpacMaintenance did not get set somehow. Kind Regards, Chris
Greetings,
SEMI-MAJOR: The cron /etc/cron.d/koha (exactly as per Wiki, README, etc) only works if owner:group is root:root or root:koha (fails completely if koha:koha). This (because the "user koha" appears in field #6, and without it, it fails) is leading to the zebra incremental running twice: Jul 28 17:20:01 server2 CRON[2132]: (root) CMD (koha $KOHAPATH/bin/migration_tools/rebuild_zebra.pl -a -b -z &> /dev/null) Jul 28 17:20:01 server2 CRON[2135]: (koha) CMD ( $KOHAPATH/bin/migration_tools/rebuild_zebra.pl -a -b -z &> /dev/null)
Thank you for pointing out some needed improvements in the wiki documentation. - Mark Tompsett
participants (4)
-
Christopher Nighswonger -
Jared Camins-Esakov -
Mark Tompsett -
Paul