2005/04/05
IRC [04:35] *** frankie joined the chat.
IRC [05:01] *** tektubby joined the chat.
IRC [05:01] *** holycow parted the chat.
IRC [06:04] <tektubby> trying to decipher aolserver error: Warning: nsmain: rl_max > FD_SETSIZE , max files: FD_SETSIZE = 1024, rl_cur = 11095, rl_max = 0
IRC [06:09] <tektubby> creates an unstable condition: http://aolserver.am.net/cvs/aolserver/aolserver/nsd/nsmain.c
IRC [06:10] <tektubby> but what params affect this? OS?
IRC [06:21] <tektubby> rl_max = fd limit (ulimit -Hn) ? man ulimit for freebsd 4.11 says ulimit only available from sh, so maybe that's why rl_max = 0.
IRC [06:21] <tektubby> I wonder if that's something to be concerned about.
IRC [08:23] <Dossy> that isn't or shouldn't be an error, just a warning.
IRC [08:34] <jcdldn> Dossy: I had to comment out that if (sizeof(int) < sizeof(long)) { Tcl_Panic("NsTclInitObjs: sizeof(int) < sizeof(long)"); }
IRC [08:35] <jcdldn> in tclobj.c and so far anyway there have been no problems at all.
IRC [08:36] <jcdldn> as it broke nsd on the dual opteron box we just got.
IRC [08:41] <Dossy> yup.
IRC [08:41] <jcdldn> any chance that gets into a 4.0.x release or someone looks and sees whether just ignoring that check is ok?
IRC [08:42] <Dossy> That test should be demoted to just logging a warning (possibly an error);.
IRC [08:42] <jcdldn> It certainly hasn't been a problem but we are still just playing with that server...
IRC [08:43] <Dossy> well, ignoring the check isn't "okay" - if you have a custom C module which wasn't coded properly to be 64-bit safe ...
IRC [08:43] <Dossy> say, one that uses struct{}'s with 32-bit long's
IRC [08:43] <Dossy> and you have code that just write(fd, &struct, sizeof(struct)) it to a disk file
IRC [08:44] <Dossy> well, if you recompile that code for 64-bit and it has LP64 ... the logs will be 64-bit and the struct won't match up and reading the data files back in = corrupted
IRC [08:44] <Dossy> that's the ONE reason why that check is in there, as far as I can tell
IRC [08:44] <Dossy> (yes, I've been struggling to come up with a real reason to have that test in there)
IRC [08:45] <Dossy> brb
IRC [10:33] <tektubby> right. Dossy, a warning. Though, according to the code comments, the warning suggests of an impending error due to instability issues, right? Or do I need to identify the real value of ulimit -Hn to see if the warning is valid?
IRC [10:43] <Dossy> the warning is just that the limit exceeds FD_SETSIZE, which can break lots of things.
IRC [10:43] <Dossy> such as some implementations of select()
IRC [10:43] <Dossy> and older OS'es where fd's were unsigned char (limit = 256) where FD_SETSIZE=256 ...
IRC [10:50] <tektubby> ok so, it can be be safely ignored unless maybe there are unexplained serious errors occuring. thanks.
IRC [11:06] <Dossy> yeah
IRC [11:07] <Dossy> well, it shouldn't be ignored - if you didn't intend to set the rlimit that high, then you should lower it
IRC [11:17] <tektubby> what ns param?
IRC [11:31] *** port001 joined the chat.
IRC [11:36] <Dossy> it's not an ns_param
IRC [11:37] <Dossy> you set it in the parent process that's starting nsd
IRC [11:37] <Dossy> if that happens to be a shell, then set it there
IRC [11:38] <Dossy> if you use daemontools, there's "softlimit"
IRC [11:38] <Dossy> you mentioned freebsd - could use daemontools' softlimit wrapper, or a shell script wrapper.
IRC [11:47] <tektubby> hmm ok
IRC [12:11] <olafm> Ho Dossy, did my email arrive this time around?
IRC [12:12] <olafm> s/Ho/Hi/
IRC [12:15] *** frankie parted the chat.
IRC [13:49] *** holycow joined the chat.
IRC [13:50] *** frankie joined the chat.
IRC [14:02] <Dossy> olafm: yeah, got your mail -- will try to check it out later.
IRC [14:11] <olafm> Ok
IRC [15:27] *** tektubby parted the chat.
IRC [17:12] *** frankie parted the chat.
IRC [20:12] <Dossy> aim, tcl-coredumper
IRC [20:12] <Dossy> tcl-coredumper
IRC [20:35] *** jcdldn parted the chat.
IRC [21:04] *** port001 parted the chat.
IRC [23:29] *** cdcarter joined the chat.
IRC [23:30] *** cdcarter parted the chat.