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

    ue_21 Stops Unexpectedly; ue_21 Restart Required After p_publish_04

    • Article Type: General
    • Product: Aleph
    • Product Version: 20

    One of our consortial partners reported a Course Reserves item that wasn't in Primo yesterday. While investigating the problem, I found that ue_21 has not been running on production in ABC30 since 3/16. The end of the last ue_21 log in abc30/scratch is below.

    Any idea why this may have crashed? Also, is there any recommended practice for ensuring that a crash like this is reported out somewhere? It's unfortunate that this went unnoticed for so long, and resulted in a backlog of over 2200 Z07P records in the ABC30 processing queue.

    I've since restarted the process, Z07P is now empty, and presumably tonight publish_04 job will pick up all affected records.

    Looking at the abc30 $data_scratch/run_e_21.3794, I see this:

    HANDLING DOC NO. - NYU30.000081285 19:13:54
    HANDLING DOC NO. - NYU30.000079716 19:17:24
    EXITING - 19:20:10

    This is the result of the p_publish_04 which (as seen in the $alephe_scratch/abc30_p_publish_04.00155 log) was started at 19:20:05.
    p_publish_04 doesn't want ue_21 running.

    The $aleph_proc/p_publish_04 has these lines:
    touch $data_scratch/util_e_21_stop
    rm $data_scratch/util_e_21_stop
    at the end.

    But this second line doesn't cause ue_21 to be restarted. It just *allows* it to be restarted.

    Normally p_publish_04 is a one-time job. Once the initial run is done, ue_21 takes over and creates the Z00Ps.

    For now: If you need to run p_publish_04, you should restart ue_21 when it is done.

    As described in KB 16384-21105 we recommend stopping/starting Aleph weekly -- even if you aren't stopping Oracle.

    If something should fall through the cracks like this, it will at least be covered by this restart....

    (Keywords: p-publish-04)

    • Article last edited: 10/8/2013
    • Was this article helpful?