It may be memory but I would expect to see malloc errors (ARERR 300) in the arerror.log if this was the case. The fact you're not seeing a stack trace like this;
Mon Sep 20 08:33:52 2010 6 Timestamp: Mon Sep 20 2010 08:33:52.1865 Thread Id: 4 Version: 7.1.00 Patch 009 201009200800 ServerName: test71 Database: SQL -- Oracle Hardware: sun4u OS: SunOS 5.10 RPC Id: 337 RPC Call: 106 (GLXS) RPC Queue: 390600 Client: User Demo from Remedy Administrator (protocol 13) at IP address 192.168.1.54 Form: Logging On: suggests it may be a recursive filter - on Solaris this often causes a crash without logging anything useful. Check to see whether there are any core files in the server/bin directory as this is another symptom of this type of crash on Solaris. If cores are enabled (check with the OS coreadm command) then the server may create them even though you're not running a debug build. If you do have some core files then run the pstack command against them (pstack core) and you will be able to see the stack of each thread within the server - if it is a recursive filter causing a stack overflow then one of the threads should stand out as being much bigger than the others. Depending on what you see you may then need to enable FILTER/SQL logging to try and capture the workflow that is causing the crash. It's also worth checking the Filter-Max-Stack value in ar.conf - various installers set this to a very high value - try reducing it back down to 50 or so and this should stop most filter recursion crashes and log an error instead. Mark I work for BMC, I don't speak for them. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of patrick zandi Sent: 22 September 2011 21:07 To: arslist@ARSLIST.ORG Subject: ARS 7.1 P6 Server -- 4 days restarting (possible memory OS 32bit issue) signal is 11 ** Just a Quick Question:: ARS 7.1 P6 :: on solaris 10, I am seeing a Operating system telling the ars to shutdown about every 4 -6 days.. not positive, nothing in debugging of logs at all, only in the ARMONITOR.log where it says.. 2011 ARMonitor child process (pid:15277) died with 11. And the signal is 11. ./arserverd Can I assume Signal 11 is Memory? --- I have seen alot of memory issues with a 11 signal in the arslist... -- Patrick Zandi _attend WWRUG11 www.wwrug.com<http://www.wwrug.com> ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
