I think what I'm going to try then today is plug a spare SATA hard drive
into the SR1520, set it up as a raid0, let the CLN pick it up, and
designate it as swap (or I guess I could use LVM and do the same?) and
see if that fixes things as well. If so, then the simplest thing to
instruct CLN users to do is make sure they allot swap prior to
attempting OpenAFS.
Ed L. Cashin wrote:
On Thu, Mar 29, 2007 at 08:00:49PM -0500, Tony Shadwick wrote:
I won't call it "fixed", but with much help from the guys in #openafs,
we did get things working.
That's great!
...
The stack size is set to 8192. We had to change that to unlimited,
then things started working, so ulimit -s unlimited.
I see.
Ed, if you see this...any thoughts on what might cause this?
Well, an OpenAFS process probably has a large array or similar data
structure on its stack (usually a function-local variable in a C
program).
The ulimit is a system setting that prevents processes from using a
large amount of memory for stack space. On the CLN or other server,
especially one without swap space, that limit could help to prevent a
greedy user process from consuming the RAM that the system needs to
perform well.
The setting is a trade off. By removing the limit, you give processes
greater freedom while losing the stability that the limit can provide.
In the end, user processes can usually perform a denial of service
attack somehow on the local host, whether it's with the notorious
"fork bomb" or some more insidious exploitation of a weakness in the
kernel. Still, multi-level security is a good policy.
I've been instructed to file a bug report on openafs-bugs, and to debian
regarding the package, as the /etc/init.d/openafs-filserver script has
to be modified to do ulimit -s unlimited at each startup, as the setting
is a per-session thing. Speculation as to the cause is welcome.
A per-session setting sounds like a good solution.
Please don't think a small thing of this. I've spent well over 40
hours, along with the help of several people to weed this out!
Yes, it sounds like it was quite a lot of work. I'm glad that the
OpenAFS developers were so helpful and responsive, and I hope that
your solution will be found by others in the mailing list archives.
Congrats on recruiting allies and tracking it down!
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
