eDirectory v9.0.4 IDM 4.6.2.0 Will not start

eDirectory for Linux x86_64 v9.0.4 [DS] - DirXML version is 4.6.2.0 SE
Multiple instances
non-root install.
Can not start eDirectory.

#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007fa02f9a0b59, pid=4048, tid=0x00007fa00ad79700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_152-b16) (build 1.8.0_152-b16)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.152-b16 mixed mode linux-amd64 compressed oops)
from hs_err_pid###.log
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f69b6125b59, pid=3064, tid=0x00007f6991802700
--------------- T H R E A D ---------------
Current thread (0x000000002a64f000): JavaThread "\PILOTUNIXAUTH\pilot\nationwidedir\esc\dirxml\DirXMLDriverSet\Unix Auth to IDV"

So how can I remove this server from the driver set or disable the driver when eDirectory will not run.



Have other servers in tree running as root with no apparent issues on v9.0.3 or v9.0.4 [DS] - DirXML version is 4.6.0.0 SE.

Was also wondering if anyone else is running Multiple-instances?


Questions, Comments and Suggestions are always encouraged!

-jim
Parents
  • On 8/16/2018 12:44 PM, jwilleke wrote:
    >
    > eDirectory for Linux x86_64 v9.0.4 [DS] - DirXML version is 4.6.2.0 SE
    > *Multiple instances*
    > *non-root install.*
    > Can not start eDirectory.
    >
    >
    > Code:
    > --------------------
    > #
    > # A fatal error has been detected by the Java Runtime Environment:
    > #
    > # SIGSEGV (0xb) at pc=0x00007fa02f9a0b59, pid=4048, tid=0x00007fa00ad79700
    > #
    > # JRE version: Java(TM) SE Runtime Environment (8.0_152-b16) (build 1.8.0_152-b16)
    > # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.152-b16 mixed mode linux-amd64 compressed oops)
    > from hs_err_pid###.log
    > #
    > # A fatal error has been detected by the Java Runtime Environment:
    > #
    > # SIGSEGV (0xb) at pc=0x00007f69b6125b59, pid=3064, tid=0x00007f6991802700
    > --------------- T H R E A D ---------------
    > Current thread (0x000000002a64f000): JavaThread "\PILOTUNIXAUTH\pilot\nationwidedir\esc\dirxml\DirXMLDriverSet\Unix Auth to IDV"
    >
    > So how can I remove this server from the driver set or disable the driver when eDirectory will not run.
    >
    > --------------------
    >
    >
    >
    > Have other servers in tree running as root with no apparent issues on
    > v9.0.3 or v9.0.4 [DS] - DirXML version is 4.6.0.0 SE.
    >
    > Was also wondering if anyone else is running Multiple-instances?
    >
    >
    > Questions, Comments and Suggestions are always encouraged!


    David has been working on an issue in 4.7 that sounds slightly familiar.

    The old trick of moving libvrdim.so out of the proper dir, restarting
    eDir so IDM does not load seems to break in 4.7 but libdxevent does seem
    to help I think he said.


  • On 08/16/2018 11:01 AM, Geoffrey Carman wrote:
    > On 8/16/2018 12:44 PM, jwilleke wrote:
    >>

    > The old trick of moving libvrdim.so out of the proper dir, restarting eDir
    > so IDM does not load seems to break in 4.7 but libdxevent does seem to
    > help I think he said.


    Break how? Meaning it does not prevent libvrdim from loading? That's
    surprising, though to be clear, I have never thought renaming libvrdim.so
    was the best way to do this. Since that is just a symlink, and there are
    others in there, it is best to move the real file, which is
    libvrdim.so.blah.blah.600 (or something like that). Whatever the one real
    (vs. symlink) file is, move that out. This breaks all symlinks, and then
    prevents IDM from starting since it cannot rely on some other, missed,
    symlink, or the real file itself, to load.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • On 8/17/2018 8:45 AM, ab wrote:
    > On 08/16/2018 11:01 AM, Geoffrey Carman wrote:
    >> On 8/16/2018 12:44 PM, jwilleke wrote:
    >>>

    >> The old trick of moving libvrdim.so out of the proper dir, restarting eDir
    >> so IDM does not load seems to break in 4.7 but libdxevent does seem to
    >> help I think he said.

    >
    > Break how? Meaning it does not prevent libvrdim from loading? That's
    > surprising, though to be clear, I have never thought renaming libvrdim.so
    > was the best way to do this. Since that is just a symlink, and there are
    > others in there, it is best to move the real file, which is
    > libvrdim.so.blah.blah.600 (or something like that). Whatever the one real
    > (vs. symlink) file is, move that out. This breaks all symlinks, and then
    > prevents IDM from starting since it cannot rely on some other, missed,
    > symlink, or the real file itself, to load.


    I think eDir was failing to start in David's case, due to IDM. So do not
    load the IDM components so you can go fix the IDM components in eDir.
    But the old trick did not let eDir start and had to move the dxevent lib
    instead to et it to work in 4.7.

  • Looks like the current documentation may need clarified.
    https://www.netiq.com/documentation/identity-manager-47/driver_admin/data/bkk05ox.html

    "Move the libvrdim.* files from their original directory to a different directory.
    The files are located in the /opt/novell/eDirectory/lib/nds-modules/ directory."
Reply Children
  • On 08/18/2018 02:54 AM, jwilleke wrote:
    >
    > Looks like the current documentation may need clarified.
    > https://www.netiq.com/documentation/identity-manager-47/driver_admin/data/bkk05ox.html
    >
    > "Move the libvrdim.* files from their original directory to a different
    > directory.
    > The files are located in the /opt/novell/eDirectory/lib/nds-modules/
    > directory."


    Perhaps, but unless the steps listed were the ones tried, they may still
    be correct. Moving one symlink, but leaving the actual file and other
    symlinks, is not the same as moving all files (symlinks plus real data).
    I always just moved the real file because it's simpler, and it breaks the
    symlinks (effectively making them invalid). If the other file also needs
    to be moved, then so be it, but the only test we know was done it, at
    best, incomplete.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.