[Koha] problem importing marc records

[Huck]

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
>