Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting]
At 07:40 PM 8/22/2012 -0300, Tomas Cohen Arazi wrote: Tomas,
and besides that, Koha runs flawlessly for of us on 64 bit servers, runnning on Ubuntu LTS distro (12.04 and 10.04).
People just told you how to circumvent those issues.
Thanks for the reply -- I'm convinced that everyone is working towards the same goal. But, despite never having had this problem on 3.6.1, 4, 6, 7, I just can't get beyond it on 3.8.3 and 4. It *must* be my mistake (maybe a totally dumb one), but after four installs I'm back to a non-functional zebra. Coming back to my original issue -- 3.8.4 (after another full install) is showing the same error as 3.8.3 -- idzebra-2.0 is fully [??? an 'apt-get idzebra-2.0' comes up with "latest version" and no missing dependencies ???] installed but there's no daemon! So I must have missed something in the repositories/dependences. paul@server:~$ sudo /etc/init.d/koha-zebra-daemon start Starting Zebra Server /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found I am now convinced that somehow, somewhere, zebra is *NOT* properly installed. So before I go any further and screw something up, here's where I'm at as far as Zebra is concerned: /etc/init.d/koha-zebra-daemon has the proper symlink: paul@server:/etc/init.d$ ls -l | grep koha lrwxrwxrwx 1 root root 37 Aug 22 19:11 koha-zebra-daemon -> /usr/share/koha/bin/koha-zebra-ctl.sh and that is the file that has the line 73 that causes the error: daemon --name=$NAME --errlog=$ERRLOG --stdout=$STDOUT --output=$OUTPUT --verbose=1 --respawn --delay=30 $OTHERUSER -- $ZEBRASRV $ZEBRAOPTIONS -f $KOHA_CONF koha-conf.xml has the user as 'koha' with the correct password, and the output belongs to 'koha': paul@server:/var/lock/koha/zebradb$ ls -l total 0 drwxr-xr-x 2 koha koha 40 Aug 22 19:48 authorities drwxr-xr-x 2 koha koha 40 Aug 22 19:48 biblios I guess that I can get back to things tomorrow and try manually installing: idzebra-2.0-common idzebra-2.0-doc idzebra-2.0-utils libidzebra-2.0-0 libidzebra-2.0-dev libidzebra-2.0-mod-alvis libidzebra-2.0-mod-grs-marc libidzebra-2.0-mod-grs-regx libidzebra-2.0-mod-grs-xml libidzebra-2.0-mod-text libidzebra-2.0-modules but I would have thought that idzebra-2.0 contained all the necessary dependences, or would have reported anything missing. Best -- P. --- 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 2012-08-23, at 12:36 PM, Paul wrote:
At 07:40 PM 8/22/2012 -0300, Tomas Cohen Arazi wrote: Tomas,
and besides that, Koha runs flawlessly for of us on 64 bit servers, runnning on Ubuntu LTS distro (12.04 and 10.04).
People just told you how to circumvent those issues.
Thanks for the reply -- I'm convinced that everyone is working towards the same goal. But, despite never having had this problem on 3.6.1, 4, 6, 7, I just can't get beyond it on 3.8.3 and 4. It *must* be my mistake (maybe a totally dumb one), but after four installs I'm back to a non-functional zebra.
Coming back to my original issue -- 3.8.4 (after another full install) is showing the same error as 3.8.3 -- idzebra-2.0 is fully [??? an 'apt-get idzebra-2.0' comes up with "latest version" and no missing dependencies ???] installed but there's no daemon! So I must have missed something in the repositories/dependences.
paul@server:~$ sudo /etc/init.d/koha-zebra-daemon start Starting Zebra Server /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found
$ sudo apt-get install daemon ? (i'm not why you are missing that package)
paul@server:~$ sudo /etc/init.d/koha-zebra-daemon start Starting Zebra Server /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found
$ sudo apt-get install daemon ?
(i'm not why you are missing that package)
my other hunch is that you have bunch of __FOO__ stuff in your /etc/init.d/koha-zebra-daemon file like this.. USER=__KOHA_USER__ GROUP=__KOHA_GROUP__ DBNAME=__DB_NAME__ NAME=koha-zebra-ctl.$DBNAME LOGDIR=__LOG_DIR__ ERRLOG=$LOGDIR/koha-zebradaemon.err STDOUT=$LOGDIR/koha-zebradaemon.log OUTPUT=$LOGDIR/koha-zebradaemon-output.log KOHA_CONF=__KOHA_CONF_DIR__/koha-conf.xml RUNDIR=__ZEBRA_RUN_DIR__ LOCKDIR=__ZEBRA_LOCK_DIR__ # you may need to change this depending on where zebrasrv is installed ZEBRASRV=__PATH_TO_ZEBRA__/zebrasrv ZEBRAOPTIONS="-v none,fatal,warn" which is causing your script to fail...
At 01:50 PM 8/23/2012 +1200, Mason James wrote:
paul@server:~$ sudo /etc/init.d/koha-zebra-daemon start Starting Zebra Server /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found $ sudo apt-get install daemon ?
Thanks - that was the problem, and I have no idea why it "went AWOL."
my other hunch is that you have bunch of __FOO__ stuff in your /etc/init.d/koha-zebra-daemon file
That had installed perfectly, but thanks, it pushed me into doing a lot more digging around. Anyway, as of this morning, Koha 3.8.4 is running on AMD64 Ubuntu 12.04 LTS. However, I have (after asking our staff to try it out), got a very weird dilemma: from the new test machine, all NEW records (biblios and items, both Z39.50 imports and manual entries) are saving to our *PRODUCTION* server (3.6.1) -- all EDITS of existing biblios/items are saving correctly to the *TEST* server (3.8.4). Both servers are on the same LAN, but under different computer names 'server' and 'nelson', different IPs 192.168.0.91 and .95, different db names 'koha' and 'koha384', different URLs 'http://koha' and 'http://koha-admin' compared to 'http://koha3' and 'http://koha-admin3', hosts files all updated, router updated (static, no DHCP). Similarities are that I restored a mysql dump from production to test and therefore users/staff logins/passwords are the same. The test machine is saving something: we experimented with entering a new book by an existing author; on the "1 tab" when cataloging and checking the "authority" (little red box at the end of the 100$a line) it correctly incremented the number of times "Used" from 4 to 5 - 6 - 7 each time we saved that book - but a subsequent "authority" search only found the 4 again. However, now (accidentally) checking the production machine, an "authority" search finds all 7 !!! with the associated biblios and items. Anyone got any thoughts? Is there something is the mysql "restore" that points to the wrong db? [I used 'mysql --user=<me> --password=my_pw koha384 < /usr/share/koha/koha361dump_1jan12.sql] I have fairly detailed installation notes if anyone would like them... but as I'll probably do another complete reinstall (before upgrading the production machine mid-September), I will verify and refine them -- then try and assist with the "documentation project." Thanks - Paul
Paul: I'm wondering if you could have the staffClientBaseURL system preference set (not changed after loading the database from the production server)? If so, logging in to the staff interface on the test server may be "sending" you to the production server? --Robert ********************************************* Robert L. Williams Manager, Open Source ILS Services Amigos Library Services, Inc. 14400 Midway Road Dallas, TX 75244-3509 800-843-8482, x2870 972-340-2870 (direct) 972-991-6061 (fax) -----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Paul Sent: Friday, August 24, 2012 12:38 PM To: Koha Devel Cc: Koha Devel Subject: Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] At 01:50 PM 8/23/2012 +1200, Mason James wrote:
paul@server:~$ sudo /etc/init.d/koha-zebra-daemon start Starting Zebra Server /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found $ sudo apt-get install daemon ?
Thanks - that was the problem, and I have no idea why it "went AWOL."
my other hunch is that you have bunch of __FOO__ stuff in your /etc/init.d/koha-zebra-daemon file
That had installed perfectly, but thanks, it pushed me into doing a lot more digging around. Anyway, as of this morning, Koha 3.8.4 is running on AMD64 Ubuntu 12.04 LTS. However, I have (after asking our staff to try it out), got a very weird dilemma: from the new test machine, all NEW records (biblios and items, both Z39.50 imports and manual entries) are saving to our *PRODUCTION* server (3.6.1) -- all EDITS of existing biblios/items are saving correctly to the *TEST* server (3.8.4). Both servers are on the same LAN, but under different computer names 'server' and 'nelson', different IPs 192.168.0.91 and .95, different db names 'koha' and 'koha384', different URLs 'http://koha' and 'http://koha-admin' compared to 'http://koha3' and 'http://koha-admin3', hosts files all updated, router updated (static, no DHCP). Similarities are that I restored a mysql dump from production to test and therefore users/staff logins/passwords are the same. The test machine is saving something: we experimented with entering a new book by an existing author; on the "1 tab" when cataloging and checking the "authority" (little red box at the end of the 100$a line) it correctly incremented the number of times "Used" from 4 to 5 - 6 - 7 each time we saved that book - but a subsequent "authority" search only found the 4 again. However, now (accidentally) checking the production machine, an "authority" search finds all 7 !!! with the associated biblios and items. Anyone got any thoughts? Is there something is the mysql "restore" that points to the wrong db? [I used 'mysql --user=<me> --password=my_pw koha384 < /usr/share/koha/koha361dump_1jan12.sql] I have fairly detailed installation notes if anyone would like them... but as I'll probably do another complete reinstall (before upgrading the production machine mid-September), I will verify and refine them -- then try and assist with the "documentation project." Thanks - 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/
On 2012-08-25, at 5:37 AM, Paul wrote:
At 01:50 PM 8/23/2012 +1200, Mason James wrote:
paul@server:~$ sudo /etc/init.d/koha-zebra-daemon start Starting Zebra Server /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found $ sudo apt-get install daemon ?
Thanks - that was the problem, and I have no idea why it "went AWOL."
my guess is that you cocked-up step 1.5 of the Koha ubuntu install guide? $ sudo dpkg --set-selections < install_misc/ubuntu.packages http://git.koha-community.org/cgi-bin/gitweb.cgi?p=koha.git;a=blob;f=INSTALL... cheers...
At 09:16 AM 8/25/2012 +1200, Mason James wrote:
my guess is that you cocked-up step 1.5 of the Koha ubuntu install guide? $ sudo dpkg --set-selections < install_misc/ubuntu.packages
http://git.koha-community.org/cgi-bin/gitweb.cgi?p=koha.git;a=blob;f=INSTALL... cheers...
my guess is $ sudo dpkg --set-selections < install_misc/ubuntu.packages has some errors. I've offered to supply the documentation, others on this dev list have confirmed that it's not exactly up-to-date, so on and so forth... Please don't accuse me of "cocking up"
On 2012-08-25, at 10:29 AM, Paul wrote:
At 09:16 AM 8/25/2012 +1200, Mason James wrote:
my guess is that you cocked-up step 1.5 of the Koha ubuntu install guide? $ sudo dpkg --set-selections < install_misc/ubuntu.packages http://git.koha-community.org/cgi-bin/gitweb.cgi?p=koha.git;a=blob;f=INSTALL... cheers...
my guess is
$ sudo dpkg --set-selections < install_misc/ubuntu.packages
has some errors.
nope, looks fine to me... $ grep -n daemon ./install_misc/ubuntu.packages 3:daemon install
At 11:47 AM 8/25/2012 +1200, Mason James wrote:
On 2012-08-25, at 10:29 AM, Paul wrote:
At 09:16 AM 8/25/2012 +1200, Mason James wrote:
my guess is that you cocked-up step 1.5 of the Koha ubuntu install guide? $ sudo dpkg --set-selections < install_misc/ubuntu.packages
http://git.koha-community.org/cgi-bin/gitweb.cgi?p=koha.git;a=blob;f=INSTALL...
cheers...
my guess is
$ sudo dpkg --set-selections < install_misc/ubuntu.packages
has some errors.
nope, looks fine to me...
$ grep -n daemon ./install_misc/ubuntu.packages 3:daemon install
Agree - line 3 says that, but I'm still wondering why I've been there (four times at least), done it (four times), not succeeded (four times). It has something to do with amd64 vice i386 12.04 LTS. What I will do is try a more recent .ISO -- maybe ubuntu-12.04-server-amd64.iso, build 20120424.1 is not the latest, or best, or most bullet-proof. And in any|all case, it does NOT solve my problem of why the test machine is saving to a totally separate db on the production server.
nope, looks fine to me...
$ grep -n daemon ./install_misc/ubuntu.packages 3:daemon install
Agree - line 3 says that, but I'm still wondering why I've been there (four times at least), done it (four times), not succeeded (four times). It has something to do with amd64 vice i386 12.04 LTS. What I will do is try a more recent .ISO -- maybe ubuntu-12.04-server-amd64.iso, build 20120424.1 is not the latest, or best, or most bullet-proof.
And in any|all case, it does NOT solve my problem of why the test machine is saving to a totally separate db on the production server.
thats a completely separate problem, for a completely new topic thread
participants (3)
-
Mason James -
Paul -
Robert Williams