<div dir="ltr">Thank you Chris.<div><br></div><div>Yes, I can see files being created in /tmp including recently, verified permissions on /tmp and the files is correct, etc.  (we're using a single server instance).</div>
<div><br></div><div>So, the MARC file gets uploaded OK, but then when vandelay goes to do its thing it throws the "unable to read MARC file" error.  :-/</div><div><br></div><div>Other ideas, folks?</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Nov 27, 2013 at 10:26 AM, Sharp, Chris <span dir="ltr"><<a href="mailto:csharp@georgialibraries.org" target="_blank">csharp@georgialibraries.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Jeff,<br>
<br>
The directory on the server is defined in /openils/conf/opensrf.xml in the <open-ils.vandelay> section (by default it's /tmp).  As the inline comments in that file indicate, if you're in a multi-server setup, that directory needs to be a writeable NFS share.  In our case it's /openils/var/data/offline/vandelay, but that's probably not a standard location.  If you can track down whether the files are being created on the server, that might be the clue you're looking for.<br>

<br>
Hope that helps,<br>
<br>
Chris<br>
<div><div class="h5"><br>
----- Original Message -----<br>
> From: "Jeff Green" <<a href="mailto:jeff.green.ca@gmail.com">jeff.green.ca@gmail.com</a>><br>
> To: "Alexey Vladimirovich Lazar" <<a href="mailto:alexey.lazar@mnsu.edu">alexey.lazar@mnsu.edu</a>><br>
> Cc: "<<a href="mailto:evergreen-admin@list.evergreen-ils.org">evergreen-admin@list.evergreen-ils.org</a>>" <<a href="mailto:evergreen-admin@list.evergreen-ils.org">evergreen-admin@list.evergreen-ils.org</a>><br>

> Sent: Tuesday, November 26, 2013 7:54:22 PM<br>
> Subject: Re: [Evergreen-admin] Staff Client MARC Batch Import Failure<br>
><br>
><br>
><br>
> Hi Aleksey. Responses to your questions below.<br>
><br>
><br>
> Anyone know what the mechanism is for uploading the MARC file from<br>
> the staff client into the vandelay module, and what could fail<br>
> during that process? When I check the relevant Perl I see that the<br>
> error message is supposed to include the filename, but the log just<br>
> shows null at that position, therefore I am wondering if the data is<br>
> even making it to the vandelay module.<br>
><br>
><br>
><br>
> We did not make any other system changes - only restarted services as<br>
> it had been a while. Performance degradation over time (3-4 months)<br>
> is fairly normal for us.<br>
><br>
><br>
> Yes, our service restart included apache, memcache, and ejabberd as<br>
> well as the Evergreen services. We have also since restarted<br>
> postgres.<br>
><br>
><br>
> No new errors in the postgres log, and nothing thrown during the<br>
> transaction.<br>
><br>
><br>
> We'll discuss the possibility of testing on a newer release to see if<br>
> we can reproduce the issue there.<br>
><br>
><br>
><br>
> On Mon, Nov 25, 2013 at 9:23 AM, Lazar, Alexey Vladimirovich <<br>
> <a href="mailto:alexey.lazar@mnsu.edu">alexey.lazar@mnsu.edu</a> > wrote:<br>
><br>
><br>
><br>
> On 2013-11-24, at 10:45 , Jeff Green < <a href="mailto:jeff.green.ca@gmail.com">jeff.green.ca@gmail.com</a> ><br>
> wrote:<br>
><br>
> > After restarting our Evergreen services several weeks ago (due to<br>
> > some slowness), we've been unable to use the MARC Batch Import<br>
> > feature in the staff client.<br>
><br>
> Did you make any other changes to the system? Is it possible the<br>
> slowness cause some system corruption?<br>
><br>
><br>
> > We've tried using multiple computers on multiple networks, various<br>
> > MARC files, and have restarted the Evergreen services several<br>
> > times.<br>
><br>
> When you restarted Evergreen services, did you also restart ejabberd?<br>
><br>
><br>
> > I also bumped up the loglevel but didn't find any more useful<br>
> > information.<br>
><br>
> Are you seeing any postgresql errors?<br>
><br>
> > Running on Evergreen 2.2.0<br>
><br>
> Kind of an old version -- many bug fixes and improvements since then,<br>
> including with speed and security. Do you have a test system where<br>
> you could try a newer version of Evergreen, like 2.4.something? If<br>
> yes, try the MARC uploading there.<br>
><br>
> Aleksey Lazar<br>
> IS Developer and Integrator - PALS<br>
> <a href="http://www.mnpals.org/" target="_blank">http://www.mnpals.org/</a><br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> Jeff Green<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> Evergreen-admin mailing list<br>
> <a href="mailto:Evergreen-admin@list.evergreen-ils.org">Evergreen-admin@list.evergreen-ils.org</a><br>
> <a href="http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-admin" target="_blank">http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-admin</a><br>
><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Chris Sharp<br>
PINES System Administrator<br>
Georgia Public Library Service<br>
1800 Century Place, Suite 150<br>
Atlanta, Georgia 30345<br>
(404) 235-7147<br>
<a href="mailto:csharp@georgialibraries.org">csharp@georgialibraries.org</a><br>
<a href="http://pines.georgialibraries.org/" target="_blank">http://pines.georgialibraries.org/</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Jeff Green<br><br>
</div>