Skip to main content
ExLibris
  • Subscribe by RSS
    • Back
    Aleph
    Ex Libris Knowledge Center

    Batch que won't shut down; lib_batch_log at 2 Gig; "lib_batch already running"

    1. Last updated
    2. Save as PDF
    • Article Type: General
    • Product: Aleph
    • Product Version: 20

    Description:
    Since a v20 instance was installed on the server with our existing v17 instance, we have been having the following (batch queue) problems:
    (1) aleph_shutdown does not complete. The log shows that it is stopping in trying to stop the batch queue for the abc30 library.
    (2) The abc30 UTIL-C-1 shows that some job is always running repeatedly;
    (3) After killing this job and stopping the queue, when we try starting the abc30 batch queue (UTIL-C-2), there is no error message but it doesn't actually start either.
    (4) I find that if I scroll up from the screen where I did the UTIL-C-2, that a message (which apparently flashed by very quickly) appears:
    /exlibris/aleph/u18_1/abc30/files/lib_batch_log
    Filesize limit exceeded
    "ls -lrt" in the ./abc30/files/ directory shows that the lib_batch_log is at 2 Gig (2147483647 bytes).
    (5) When I connected to v17 and tried to start the abc50 batch queue (UTIL-C-2), I got the message "lib_batch already running for ABC50" -- even though UTIL-C-1 did *not* show any lib_batch running.
    >> ps -ef | grep lib_batch | grep ABC50
    showed that the only lib_batch ABC50 process running was the v20 process.

    Thinking it might be confused, I killed this v20 process.

    When I then did UTIL-C-2 for the v17 abc50, the (v17) lib_batch process started.

    Now when I do
    >> ps -ef | grep lib_batch | grep ABC50

    I see the v17 lib_batch process but (of course) no v20.

    When I do UTIL-C-2 in v20 to try to start the lib_batch it says "lib_batch already running for ABC50" -- even though the only ABC50 lib_batch running is the v17.

    Resolution:
    The problem was that the v20 scratch and files directories have had symlinks to the v17 instance:
    lrwxrwxrwx 1 aleph exlibris 27 Jun 15 13:52 scratch -> /wrkspc/u17_1/abc50/scratch/
    lrwxrwxrwx 1 aleph exlibris 25 Jun 15 13:52 files -> /wrkspc/u17_1/abc50/files/

    Thus, there was an unhealthy connection between these two instances.

    For instance, when you would start the v20 lib_batch writes a que_batch_lock file to the /wrkspc/u17_1/abc50/files/ directory. The v17 UTIL-C-2 would then find this que_batch_lock and conclude that lib_batch was already running.

    The solution was to remove these symlinks.

    • Article last edited: 10/8/2013