At 06:30 PM 7/28/2012 -0400, Jared Camins-Esakov wrote:
[snip] Did you try rerunning updatedatabase?
Many thanks for the reply. Yes, but I ran paul@server2:/usr/share/koha/intranet/cgi-bin/installer/data/mysql$ perl -I updatedatabase.pl overnight - it only took a few minutes when initiated by Koha after the install. If I've made an error, could you please assist with the syntax? Also, Chris N. suggested "Also double check to be sure that OpacMaintenance did not get set somehow" -- it was set (not sure how - I didn't even realize that this preference existed) and now the OPAC is up and running. Thanks Chris.
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.
Hidden in a corner under the name 'root' I finally found it, and the cron is now working perfectly (except 'mail', see below). For the archives: $ cd /var/spool/cron $ sudo chmod 755 crontabs $ sudo vi root [change 5 mins to 1 min] :x $ cd .. $ sudo chmod 1770 crontabs
So, remove nullmailer. nullmailer needs to be configured appropriately if you are using it.
Done, and get (once a minute) syslog entries: Jul 29 13:38:01 server2 CRON[1854]: (CRON) info (No MTA installed, discarding output) which was why I was asking if there was an easy way of "turning it off" in Koha (I've looked unsuccessfully for a global O/S method to turn off "warnings) - I don't need an email every minute, 24/7 :-} -- and I'd like to reinstall nullmailer to verify all the "wanted" patron emails (no intention of installing sendmail on this sandbox; on the production server I've got sendmail to selectively dev/null unwanted messages.) Many thanks all around. I'll continue comparing this to our production box, and get some of our cataloguers to have a look over the next few days. As and when we come up with more bits and pieces, I'll have a look at helping with the Wiki page -- Tomas, I see that you have done all the editing, but have a blank "talk" page. Would you prefer to email (either on- or off-list) or use the "talk page"? Regards -- Paul
If you look carefully you will note that it is cron not Koha trying to use the mta. Which you don't have (or haven't configured) This is a much lower level OS thing, looks like you have mucked up your cron set up. Note not the koha cron jobs, but cron itself. You will want to fix that. Chris Paul <paul.a@aandc.org> wrote: At 06:30 PM 7/28/2012 -0400, Jared Camins-Esakov wrote:
[snip] Did you try rerunning updatedatabase?
Many thanks for the reply. Yes, but I ran paul@server2:/usr/share/koha/intranet/cgi-bin/installer/data/mysql$ perl -I updatedatabase.pl overnight - it only took a few minutes when initiated by Koha after the install. If I've made an error, could you please assist with the syntax? Also, Chris N. suggested "Also double check to be sure that OpacMaintenance did not get set somehow" -- it was set (not sure how - I didn't even realize that this preference existed) and now the OPAC is up and running. Thanks Chris.
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.
Hidden in a corner under the name 'root' I finally found it, and the cron is now working perfectly (except 'mail', see below). For the archives: $ cd /var/spool/cron $ sudo chmod 755 crontabs $ sudo vi root [change 5 mins to 1 min] :x $ cd .. $ sudo chmod 1770 crontabs
So, remove nullmailer. nullmailer needs to be configured appropriately if you are using it.
Done, and get (once a minute) syslog entries: Jul 29 13:38:01 server2 CRON[1854]: (CRON) info (No MTA installed, discarding output) which was why I was asking if there was an easy way of "turning it off" in Koha (I've looked unsuccessfully for a global O/S method to turn off "warnings) - I don't need an email every minute, 24/7 :-} -- and I'd like to reinstall nullmailer to verify all the "wanted" patron emails (no intention of installing sendmail on this sandbox; on the production server I've got sendmail to selectively dev/null unwanted messages.) Many thanks all around. I'll continue comparing this to our production box, and get some of our cataloguers to have a look over the next few days. As and when we come up with more bits and pieces, I'll have a look at helping with the Wiki page -- Tomas, I see that you have done all the editing, but have a blank "talk" page. Would you prefer to email (either on- or off-list) or use the "talk page"? Regards -- Paul _____________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
At 07:51 AM 7/30/2012 +1200, Chris Cormack wrote:
If you look carefully you will note that it is cron not Koha trying to use the mta. Which you don't have (or haven't configured)
This is a much lower level OS thing, looks like you have mucked up your cron set up. Note not the koha cron jobs, but cron itself.
You will want to fix that.
Thanks for the reply. OK - so I (wrongly?) bypassed crontab when I found that Ubuntu|Koha|me had created 'root' in /var/spool/cron/crontabs. The reason I'me in some doubt about whether it was Koha or me that originally created the file, is that this is the only line that started with '*/5 * *' (the Koha default from all documents that I've seen) and that I always use '5 * *' (or whatever value I want - one minute for Zebra from experience on our production server.) Also, user koha is not in the sudoers file, so cannot use crontab -e. Maybe Makefile.PL (or one of the other scripts that it calls) put it there during the time that Makefile was running as user paul (root privileges)? If I use crontab -e (just tried it), vi writes to a "/tmp/crontab.gCZpqN/crontab" which Ubuntu then moves to /var/spool/cron/crontabs/root -- not to /etc/cron.d or anywhere else. I checked our production server (Ubuntu 11.10, Koha 3.6.1) and found exactly the same set up in /var/spool/cron/crontabs/root: # Env Vars Necessary for running KOHA related Cron jobs PERL5LIB = /usr/share/koha/lib KOHA_CONF = /etc/koha/koha-conf.xml KOHA_CRON_PATH = /usr/share/koha/bin/cronjobs # ** KOHA ** # ZEBRA INDEX UPDATES incremental index updates throughout # the day for both authorities and bibs : -z means incremental # Checking for new/deleted records every: 1 MINUTE 1 * * * * perl -I $PERL5LIB $KOHA_CRON_PATH/../migration_tools/rebuild_zebra.pl -b -a -z >/dev/null 2>&1 #nightly 0 0 * * * perl -I $PERL5LIB $KOHA_CRON_PATH/../migration_tools/merge_authority.pl -n -b >/dev/null 2>&1 # is this a duplicate cron job? see /usr/share/koha/bin/cronjobs/crontab # This is my sanity check # * * * * * date > ~/date.txt Note the last three lines! I had obviously struggled with the same thought that you express here "looks like you have mucked up your cron set up" But it works ... as do all the other @hourly, @boot, etc. Ubuntu specific? I jumped from Slackware to Ubuntu more than 5 years ago, and do not have enough knowledge of other modern Linux o/s's Best - Paul
Chris
Paul <paul.a@aandc.org> wrote:
At 06:30 PM 7/28/2012 -0400, Jared Camins-Esakov wrote:
[snip] Did you try rerunning updatedatabase?
Many thanks for the reply. Yes, but I ran paul@server2:/usr/share/koha/intranet/cgi-bin/installer/data/mysql$ perl -I updatedatabase.pl overnight - it only took a few minutes when initiated by Koha after the install. If I've made an error, could you please assist with the syntax?
Also, Chris N. suggested "Also double check to be sure that OpacMaintenance did not get set somehow" -- it was set (not sure how - I didn't even realize that this preference existed) and now the OPAC is up and running. Thanks Chris.
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 instr uctions assume), or you could do things vice versa.
Hidden in a corner under the name 'root' I finally found it, and the cron is now working perfectly (except 'mail', see below). For the archives:
$ cd /var/spool/cron $ sudo chmod 755 crontabs $ sudo vi root [change 5 mins to 1 min] :x $ cd .. $ sudo chmod 1770 crontabs
So, remove nullmailer. nullmailer needs to be configured appropriately if you are using it.
Done, and get (once a minute) syslog entries: Jul 29 13:38:01 server2 CRON[1854]: (CRON) info (No MTA installed, discarding output)
which was why I was asking if there was an easy way of "turning it off" in Koha (I've looked unsuccessfully for a global O/S method to turn off "warnings) - I don't need an email every minute, 24/7 :-} -- and I'd like to reinstall nullmailer to verify all the "wanted" patron emails (no intention of installing sendmail on this sandbox; on the production server I've got sendmail to selectively dev/null unwanted messages.)
Many thanks all around. I'll continue comparing this to our production box, and get some of our cataloguers to have a look over the next few days. As and when we come up with more bits and pieces, I'll have a look at helping with the Wiki page -- Tomas, I see that you have done all the editing, but have a blank "talk" page. Would you prefer to email (either on- or off-list) or use the "talk page"?
Regards -- Paul
Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
--- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>
On 30 July 2012 10:51, Paul <paul.a@aandc.org> wrote:
At 07:51 AM 7/30/2012 +1200, Chris Cormack wrote:
If you look carefully you will note that it is cron not Koha trying to use the mta. Which you don't have (or haven't configured)
This is a much lower level OS thing, looks like you have mucked up your cron set up. Note not the koha cron jobs, but cron itself.
You will want to fix that.
Thanks for the reply. OK - so I (wrongly?) bypassed crontab when I found that Ubuntu|Koha|me had created 'root' in /var/spool/cron/crontabs.
The reason I'me in some doubt about whether it was Koha or me that originally created the file, is that this is the only line that started with '*/5 * *' (the Koha default from all documents that I've seen) and that I always use '5 * *' (or whatever value I want - one minute for Zebra from experience on our production server.)
Also, user koha is not in the sudoers file, so cannot use crontab -e. Maybe Makefile.PL (or one of the other scripts that it calls) put it there during the time that Makefile was running as user paul (root privileges)?
That's untrue, any user can use crontab -e http://linux.die.net/man/1/crontab Unless you have a cron.deny (or cron.allow), blocking it
If I use crontab -e (just tried it), vi writes to a "/tmp/crontab.gCZpqN/crontab" which Ubuntu then moves to /var/spool/cron/crontabs/root -- not to /etc/cron.d or anywhere else.
No it will most definitely not move it to /etc/cron.d
I checked our production server (Ubuntu 11.10, Koha 3.6.1) and found exactly the same set up in /var/spool/cron/crontabs/root:
# Env Vars Necessary for running KOHA related Cron jobs PERL5LIB = /usr/share/koha/lib KOHA_CONF = /etc/koha/koha-conf.xml KOHA_CRON_PATH = /usr/share/koha/bin/cronjobs
# ** KOHA ** # ZEBRA INDEX UPDATES incremental index updates throughout # the day for both authorities and bibs : -z means incremental # Checking for new/deleted records every: 1 MINUTE 1 * * * * perl -I $PERL5LIB $KOHA_CRON_PATH/../migration_tools/rebuild_zebra.pl -b -a -z >/dev/null 2>&1 #nightly 0 0 * * * perl -I $PERL5LIB $KOHA_CRON_PATH/../migration_tools/merge_authority.pl -n -b >/dev/null 2>&1 # is this a duplicate cron job? see /usr/share/koha/bin/cronjobs/crontab # This is my sanity check # * * * * * date > ~/date.txt
Note from the manpage Crontab is the program used to install, remove or list the tables used to drive the cron(8) daemon. Each user can have their own crontab, and though these are files in /var/spool/ , they are not intended to be edited directly. For SELinux in mls mode can be even more crontabs - for each range. For more see selinux(8). Chris
participants (3)
-
Chris Cormack -
Chris Cormack -
Paul