Linux Access Gateway crashing when writing to laghttpheaders and lagsoapmessages files

Access Manager setup with an Administration COnsole and Identity server on the same SLES10 server, and a Linux Access Gateway (LAG) on a seperate host. Everything was working fine and users could access protected resources, authenticate and use policy information successfully. After a week of this operation, no users could access the LAG anymore and the Administration Server reported the LAG as'not responding'. Looking at the state of the services using'/etc/init.d/novell-vmc status', one could see that the LAG had crashes as many of the services were not working. Looking at the coredump that was generated (/tmp/.dumpcore file existed), the stack trace showed the following

Thread 1 (process 18081):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0x40244f9b in __write_nocancel () from /lib/tls/libc.so.6
#2 0x401f6576 in _IO_new_file_write () from /lib/tls/libc.so.6
#3 0x401f6275 in new_do_write () from /lib/tls/libc.so.6
#4 0x401f652f in _IO_new_do_write () from /lib/tls/libc.so.6
#5 0x401f6fb2 in _IO_new_file_sync () from /lib/tls/libc.so.6
#6 0x401ec0b7 in fflush () from /lib/tls/libc.so.6
#7 0x454fe8bc in SendOriginServerHTTPRequest (clientRequest=0x80c46004,
methodName=0xa1717020 "GET", methodLength=3)
at /home/src/vishnu/53.x/legacy/s_proxy/client.c:2218
#8 0x454fea05 in SendHTTPClientRequest (clientRequest=0x80c46004, status=0)
at /home/src/vishnu/53.x/legacy/s_proxy/client.c:657
#9 0x4555876f in RES_ConnectToHost (requestBlock=0x80c46004)
at /home/src/vishnu/53.x/legacy/s_proxy/ipres.c:768

Backup the lagsoapmessages and laghttpheaders file from /var/log directory and delete them. Then disable the laghttpheaders and lagsoapmessages logging by editing the file /etc/laglogs.conf as shown below (default settings).

LOG_LEVEL=5
DEBUG_HTTP_HEADERS=0
DEBUG_SOAP_MESSAGE=0


The logging was enabled at the most verbose level and the log files were growing too large. The crash occured because we could not write to the file anymore because of the size.

This will be fixed in the SP1 build of Access Manager.