Re: [AOLSERVER] Something wrong after 2006-05-12 21:25 (was Re: Weird memory leak problem in AOLserver 3.4.2/3.x)
'Jesus' Jeff Rogers wrote: I had problems starting at the exact same time but on Solaris, where they manifested as a EINVAL return from pthread_cond_tomedwait. After a day of tracing the problem with debug builds and working with my sysadmin to track what changed (of course, nothing had) I cam to the same 1 billion second issue. Which coincidentally is the expiry time (MaxOpen and MaxIdle) set on my database connections. My system is ACS-derived, so I wouldn't be surprised if these database settings are common in other ACS-derived systems. What do you think is the reason that not all systems encounter this 1B second issue? The passage of time is the one factor inevitably shared by every system running aolserver, yet not every system barfs in the same fashion. Why? -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Something wrong after 2006-05-12 21:25 (was Re: Weird memory leak problem in AOLserver 3.4.2/3.x)
'Jesus' Jeff Rogers wrote: Simple, because it's a config file setting, not anything to do with the underlying system. If your config file has [ns/db/pool/main] MaxOpen=10 MaxIdle=10 (which I think was done to work around some ancient bug in an ancient version of the nsoracle driver) then you get the problem. If your timeouts are more reasonable or 0 to explicitly specify never timeout, then no problem. Ah. For whatever reason, in my config files MaxOpen and MaxIdle were commented out; that must be why my systems didn't encounter this problem. Not defining these two vars must have been the way the 3.2.5 config file was distributed back in the day, as this is not something I would have thought to do. Leaving them undefined seems to have no ill effect. So are people defining them to 0 or simply undefining them? -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Something wrong after 2006-05-12 21:25 (was Re: Weird memory leak problem in AOLserver 3.4.2/3.x)
Stan Kaufman wrote: Not defining these two vars must have been the way the 3.2.5 config file was distributed back in the day Yup, that was the case: http://openacs.org/doc/openacs-3/nsd.txt Interesting that that inoculated OpenACS 3.2.5 systems from this problem. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Something wrong after 2006-05-12 21:25 (was Re: Weird memory leak problem in AOLserver 3.4.2/3.x)
Dossy Shiobara wrote: Generally, the only time I've seen people config the MaxOpen and MaxIdle to 1B seconds is when they're using an ACS or OpenACS recommended configuration. It might be a good idea for the OpenACS folks to edit/update their documentation and sample configs to correct this, as well ... although it'll never be May 13, 2006 ever again, so maybe it's a non-issue. :-) Why doesn't AOLServer v4.x have problems with MaxOpen and MaxIdle set to 1B -- as they are in OpenACS 5.x configs? Do MaxOpen and MaxIdle even need to be defined at all? They weren't in OpenACS 3.2.5/AOLServer 3.3.1+ad13; what's different with the current stack? -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Something wrong after 2006-05-12 21:25 (was Re: Weird memory leak problem in AOLserver 3.4.2/3.x)
Cynthia Kiser wrote: Quoting Gustaf Neumann [EMAIL PROTECTED]: It seems, as if all problems are in tcl 8.3.*. But just a data point from the not happening here side. I have info patchlevel 8.3.2 FWIW, on my boxes where aolserver appears to function correctly, the tcl in the aolserver lib is 8.3: /usr/local/aolserver/lib/tcl8.3/ On one box I have tcl 8.3.3 installed generally, and on another 8.4.9 (as revealed by checking [info patchlevel] from tclsh). But I presume that in both cases, aolserver is still using the tcl in its lib directory, correct? Since [ns_info patchlevel] isn't implemented in 3.3.1+ad13, is there some way to tell for sure which tcl aolserver is using? Anyway, if it is the case that aolserver is using its own version of tcl, then the tcl 8.3.x is the problem theory wouldn't appear to stand. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Something wrong after 2006-05-12 21:25 (was Re: Weird memory leak problem in AOLserver 3.4.2/3.x)
Andrew Piskorski wrote: If all you want to know is the Tcl version AOLserver is using, it's trivially easy, just use the Tcl info patchlevel command from inside AOLserver. Right; duh. Thanks. So, the version of tcl my 3.3.1+ad13 sites are using is 8.3.2, and they appear to reboot without the VM and scheduled proc problems. FWIW. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Weird memory leak problem in AOLserver 3.4.2/3.x
Zachary Shaw wrote:
before may 13th nanosleep was in the form
[pid 614] nanosleep({0, 34478}, unfinished ...
after the 12th there were nanosleeps in the form
[pid 614] nanosleep({9, 934211000}, unfinished ...
This looks like a blatant clue -- to someone who understands this.
nanosleep is a *nix lib command
(http://linux.about.com/library/cmd/blcmdl2_nanosleep.htm), which makes
me think the problem may not be with AOLServer. Simple-mindedly grepping
for nanosleep through the ad33.13 source and the aolserver includes etc
returns nothing, so the code isn't calling nanosleep directly. I wonder
if this is a TCL issue, though grepping through tcl source also returns
nothing. Hmm...
one additional piece of information. It appears that our logs stopped rolling
on may 13th.
My logs are rolling just fine -- both the error and access logs. Weirder
and weirder.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] Something wrong after 2006-05-12 21:25 (was Re: Weird memory leak problem in AOLserver 3.4.2/3.x)
Dossy Shiobara wrote: No, I meant ns_info patchlevel -- to get the full version of AOLserverthat's running -- but yes, I should have asked for info patchleveltoo, to find out what version of Tcl is being used. patchlevel appears not to be a switch to ns_info in AOLserver/3.3.1+ad13 (as Janine pointed out): [17/May/2006:15:08:53][14372.11231392][-conn5-] Error: unknown command patchlevel: should be address, argv0, builddate, callbacks, config, hostname, label, locks, log, name, pageroot, pid, platform, scheduled, server, sockcallbacks, tag, tcllib, threads, version, or winnt while executing ns_info patchlevel In any case, here is info about a system that appears *not* to have this trouble: % info patchlevel 8.4.9 ns_info version: 3.3.1+ad13 uname: Linux x 2.4.27 #1 Mon Jul 4 21:39:37 PDT 2005 i686 GNU/Linux (Debian sarge) glibc: libstdc++2.10-glibc2.2 -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Weird memory leak problem in AOLserver 3.4.2/3.x
Dave Siktberg david.siktberg at WEBILITY.MD writes: restarting AOL Server last night around 11PM EDT. Scheduled procs on both were working fine up until the restart -- then none. Scheduled procs are On a development box, I just started up clones of my AOLserver/3.3.1+ad13/OpenACS 3.2.5 sites, and they appear to run fine -- including scheduled procs. I'm not seeing any VM problems either. I can also fiddle with my development server. Could this be a date-related problem? I think I'll set the system date back several days, restart, and see what happens. Any other ideas? Using the current date caused no problems for me; what was the effect of back-dating? Any other information I can provide or things I can do to help debug this? As with Janine, upgrading AOLServer is not a feasible option in the short term. Same here. Could this be an OS problem? Stan -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
