[Koha] problem importing marc records

Huck dhuckaby at hvja.org
Tue Apr 22 08:35:39 NZST 2008


n/m ;)
fiddled around in the kohaclone...and figured it was just the same as 
the unpack'n of tar.gz file..:)
groovy! git is kewlio...

so upgrade golden...staged records again...was fast staging...now 
attempting to complete again...
9 minutes in it shows a pace setting 2% completed...

this is all via the web-interface fwiw...


Huck wrote:
> am attempting to do this with GIT...as when I DL'd from the link on 
> Koha.org...it was still 3.0.0.tar.gz ...
>
> I'm not really sure how to 'UPGRADE' using git...'really sure? no...I 
> have absolutely no clue actually'...
>
> I have done a:
>
> git clone git://git.koha.org/pub/scm/koha.git kohaclone
> cd kohaclone
> git checkout -b HVJA origin
>
>
> ....
>
> have no idea what to do next ;)...will begin poking around in the 
> kohaclone directory and see if something pops up =)
>
> Joshua Ferraro wrote:
>   
>> On Mon, Apr 14, 2008 at 4:35 PM, Huck <dhuckaby at hvja.org> wrote:
>>   
>>     
>>> Koha version: 3.00.00.061
>>>
>>>  it seems to stall at exactly record #3100 every time...
>>>     
>>>       
>> Please upgrade to 3.00.00.069, there were some important fixes to
>> encoding problems in MARC::Charset.
>>
>> Josh
>>
>>   
>>     
>>>  --Huck
>>>
>>>
>>>
>>>  Joshua Ferraro wrote:
>>>
>>>     
>>>       
>>>> Hey Huck,
>>>>
>>>> First off, which version of Koha are you running (can you check the
>>>>       
>>>>         
>>> version
>>>     
>>>       
>>>> syspref, or the About section of your staff client)?
>>>>
>>>> Thanks,
>>>>
>>>> Josh
>>>>
>>>> On Mon, Apr 14, 2008 at 3:59 PM, Huck <dhuckaby at hvja.org> wrote:
>>>>
>>>>
>>>>       
>>>>         
>>>>> a little play-by-play as I attempt to complete import yet again:
>>>>>
>>>>>  www-data  7443 11.6  6.7  41792 34668 ?        S    11:44   7:22
>>>>>  /usr/bin/perl
>>>>>         
>>>>>           
>>> /usr/share/koha/intranet/cgi-bin/tools/manage-marc-import.pl
>>>     
>>>       
>>>>>  www-data  8101 21.6  4.5  28700 23236 ?        R    12:47   0:02
>>>>>  /usr/bin/perl
>>>>>         
>>>>>           
>>> /usr/share/koha/intranet/cgi-bin/tools/manage-marc-import.pl
>>>     
>>>       
>>>>>  www-data  8103 35.0  2.4  16568 12468 ?        R    12:48   0:01
>>>>>
>>>>> /usr/bin/perl
>>>>>  /usr/share/koha/intranet/cgi-bin/tools/background-job-progress.pl
>>>>>
>>>>>  so it looks like after 1 hour...it launches another
>>>>>  'manage-marc-import.pl'...then it goes away in the next 10 minutes..
>>>>>
>>>>>
>>>>>  www-data  7443 11.6  6.7  41948 34744 ?        S    11:44   7:35
>>>>>  /usr/bin/perl
>>>>>         
>>>>>           
>>> /usr/share/koha/intranet/cgi-bin/tools/manage-marc-import.pl
>>>     
>>>       
>>>>>  at this point in time...the background process disappears on the 'ps
>>>>>  aux' output...then it starts up again...in some sort of a
>>>>>         
>>>>>           
>>> loop...reoccuring
>>>     
>>>       
>>>>>  but there is no more progress on the koha page...and the disk-space
>>>>>  usage according to 'df' has not changed...
>>>>>
>>>>>
>>>>>
>>>>>  Huck wrote:
>>>>>  > Still ongoing problems...
>>>>>  > the importation seems to stall at 27%...
>>>>>  > running 'ps aux' to check processes...
>>>>>  >
>>>>>  > www-data  6861 96.5  3.5  22204 18100 ?        R    11:16   0:01
>>>>>  > /usr/bin/perl
>>>>>  > /usr/share/koha/intranet/cgi-bin/tools/background-job-progress.pl
>>>>>  >
>>>>>  > this is the only thing running...
>>>>>  > and seems to die and restart die and restart......has eaten up over
>>>>>         
>>>>>           
>>> 700
>>>     
>>>       
>>>>>  > process id's since I initially clicked the 'complete import' button.
>>>>>  >
>>>>>  > when I initially clicked 'complete import' there was another
>>>>>  > /usr/bin/perl
>>>>>         
>>>>>           
>>> /usr/share/koha/intranet/cgi-bin/some-import-process-here.pl
>>>     
>>>       
>>>>>  > that was running concurrently with the above pasted process, which is
>>>>>         
>>>>>           
>>> no
>>>     
>>>       
>>>>>  > longer running.
>>>>>  >
>>>>>  > anything I can do to debug this...or perhaps run something manually
>>>>>         
>>>>>           
>>> via
>>>     
>>>       
>>>>>  > the command-line?
>>>>>  >
>>>>>  > --Huck
>>>>>  >
>>>>>  > Galen Charlton wrote:
>>>>>  >
>>>>>  >> Hi,
>>>>>  >>
>>>>>  >> On Mon, Apr 7, 2008 at 2:04 PM, Huck <dhuckaby at hvja.org> wrote:
>>>>>  >>
>>>>>  >>
>>>>>  >>>  honestly having no clue what they do/did were used for...
>>>>>  >>>  I assumed(yes we know what that means :) that these were sort of
>>>>>  >>>  temp/log files of what mysql-bin was doing ...so in essence
>>>>>         
>>>>>           
>>> recording
>>>     
>>>       
>>>>>  >>>  every single transaction or something...
>>>>>  >>>  and the one with the highest number kept incrementing...and would
>>>>>         
>>>>>           
>>> get to
>>>     
>>>       
>>>>>  >>>  it's size limit it seems every 5 min...
>>>>>  >>>
>>>>>  >>>
>>>>>  >> These are in fact DB log files that MySQL uses to record all
>>>>>  >> transactions, and are meant to be used for backup and recovery.
>>>>>  >> Collectively they're called the MySQL binary log.  See
>>>>>  >> http://dev.mysql.com/doc/refman/5.0/en/binary-log.html for the full
>>>>>  >> details.
>>>>>  >>
>>>>>  >>
>>>>>  >>
>>>>>  >>>  so right now I'm monitoring and deleting each of the ones below
>>>>>         
>>>>>           
>>> the
>>>     
>>>       
>>>>>  >>>  highest numbered(in filename)...attempting to stave-off the 'out
>>>>>         
>>>>>           
>>> of disk
>>>     
>>>       
>>>>>  >>>  space' which was causing this process to 'hang' on Friday.
>>>>>  >>>
>>>>>  >>>
>>>>>  >> The canonical way to delete them is to do a 'reset master' from the
>>>>>  >> mysql prompt.  You can also change settings in my.cnf such as
>>>>>         
>>>>>           
>>> log_bin
>>>     
>>>       
>>>>>  >> and binlog_ignore_db to turn off these logs while you do the MARC
>>>>>  >> imports.  Note that turning off the binary log on a production
>>>>>         
>>>>>           
>>> server
>>>     
>>>       
>>>>>  >> should not be done lightly, as it is an important mechanism to use
>>>>>         
>>>>>           
>>> for
>>>     
>>>       
>>>>>  >> database recovery.
>>>>>  >>
>>>>>  >> Regards,
>>>>>  >>
>>>>>  >> Galen
>>>>>  >>
>>>>>  >>
>>>>>  > _______________________________________________
>>>>>  > Koha mailing list
>>>>>  > Koha at lists.katipo.co.nz
>>>>>  > http://lists.katipo.co.nz/mailman/listinfo/koha
>>>>>  >
>>>>>  >
>>>>>  _______________________________________________
>>>>>  Koha mailing list
>>>>>  Koha at lists.katipo.co.nz
>>>>>  http://lists.katipo.co.nz/mailman/listinfo/koha
>>>>>
>>>>>
>>>>>
>>>>>         
>>>>>           
>>>>
>>>>       
>>>>         
>>
>>   
>>     
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>
>   


More information about the Koha mailing list