Environment
Novell Access Manager 3.1.3-247 Linux Access Gateway
Situation
Symptoms:
ics_dyn process on the LAG crash multiple times per day generating core files.
Changes:
Novell Access Manager Service Pack 3 has been applied
ics_dyn process on the LAG crash multiple times per day generating core files.
Changes:
Novell Access Manager Service Pack 3 has been applied
Resolution
There is a known issue within SP3 that is causing the ics_dyn
process to crash, generate a core file and then restart itself
automatically.
In order to fix the problem, the following touch file needs to be created on the LAG:
touch /var/novell/.enableWorkCancelFix
After the file has been created, a restart of"/etc/init.d/novell-vmc" service is needed to make it effective; please note that restarting this process will cause a lack of service for the time needed for the restart operation to be completed.
The issue has been fixed with SP3 IR2.
In order to fix the problem, the following touch file needs to be created on the LAG:
touch /var/novell/.enableWorkCancelFix
After the file has been created, a restart of"/etc/init.d/novell-vmc" service is needed to make it effective; please note that restarting this process will cause a lack of service for the time needed for the restart operation to be completed.
The issue has been fixed with SP3 IR2.
Additional Information
In order to be 100% sure that you are facing this specific issue,
the only way is to look at the backtrace from the core files
generated when the ics_dyn process crash. Detailed instructions on
how to get the backtrace from the core are available in the
following document:
KB 7006047 - Troubleshooting cheat sheet - howto Troubleshoot Linux Access Gateway 3.1 crash or hang issues
Here is a sample backtrace obtained from a system experiencing this issue:
#0 0xb5af3cd3 in HTTPProxyFirstRequestData (rb=0xab869020) at /home/schoi/build_sles11/LinuxAccessGateway~AccessManager3.1_SP3/LinuxAccessGateway/legacy/s_proxy/request.h:2869
#1 0xb7fca33f in _ExecuteWork (thread=0xb5f1d3f0, work=0xab869048) at sysapi.c:637
#2 0xb7fcaeaa in _WorkThreadMain (param=0xb7fd4790) at sysapi.c:896
#3 0xb7fc6df3 in threadMain (args=0xb5f1d3f0) at nksthread.c:156 #4 0xb7d8d1b5 in start_thread () from /lib/libpthread.so.0
#5 0xb7e723be in clone () from /lib/libc.so.6
Please note that this backtrace was obtained using the proper symbols, without them will look as follows:
#0 0xb5af3cd3 in ?? () from /opt/novell/lib/proxy.so.1
#1 0xb7fca33f in ?? () from /opt/novell/bin/../lib/osplatform.so.1
#2 0xb7fcaeaa in ?? () from /opt/novell/bin/../lib/osplatform.so.1
#3 0xb7fc6df3 in ?? () from /opt/novell/bin/../lib/osplatform.so.1
#4 0xb7d8d1b5 in start_thread () from /lib/libpthread.so.0
#5 0xb7e723be in ?? () from /lib/libc.so.6
KB 7006047 - Troubleshooting cheat sheet - howto Troubleshoot Linux Access Gateway 3.1 crash or hang issues
Here is a sample backtrace obtained from a system experiencing this issue:
#0 0xb5af3cd3 in HTTPProxyFirstRequestData (rb=0xab869020) at /home/schoi/build_sles11/LinuxAccessGateway~AccessManager3.1_SP3/LinuxAccessGateway/legacy/s_proxy/request.h:2869
#1 0xb7fca33f in _ExecuteWork (thread=0xb5f1d3f0, work=0xab869048) at sysapi.c:637
#2 0xb7fcaeaa in _WorkThreadMain (param=0xb7fd4790) at sysapi.c:896
#3 0xb7fc6df3 in threadMain (args=0xb5f1d3f0) at nksthread.c:156 #4 0xb7d8d1b5 in start_thread () from /lib/libpthread.so.0
#5 0xb7e723be in clone () from /lib/libc.so.6
Please note that this backtrace was obtained using the proper symbols, without them will look as follows:
#0 0xb5af3cd3 in ?? () from /opt/novell/lib/proxy.so.1
#1 0xb7fca33f in ?? () from /opt/novell/bin/../lib/osplatform.so.1
#2 0xb7fcaeaa in ?? () from /opt/novell/bin/../lib/osplatform.so.1
#3 0xb7fc6df3 in ?? () from /opt/novell/bin/../lib/osplatform.so.1
#4 0xb7d8d1b5 in start_thread () from /lib/libpthread.so.0
#5 0xb7e723be in ?? () from /lib/libc.so.6