ulimit (was: getty/login for callback)

T. William Wells bill at twwells.uucp
Tue Apr 25 15:12:02 AEST 1989


In article <1295 at frog.UUCP> john at frog.UUCP (SuperUser) writes:
: In article <829 at twwells.uucp>, bill at twwells.uucp (T. William Wells) writes:
: > In article <1423 at cunixc.cc.columbia.edu> seth at ctr.columbia.edu (Seth Robertson) writes:
: > : In article <10065 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
: > : |It's great for testing whether your application recovers gracefully from
: > : |"file system full"-like conditions!
: > > [no, fill a file system]
: > I suspect that there are very few environments where it is reasonable
: > to fill up file systems just because you want to test out "file
: > system full" checking.
:
: However, using ulimit() to test that makes it harder to discover that your
: application recovers from that by creating another file and logging a message
: to it.

Huh? If ulimit causes a failure, one can always create or extend
another file, so long as that file is smaller than the ulimit. It is
quotas that would screw you there. And if you want to test for write
failure on the additional file, that too can be arranged simply
enough.

: If you aren't going to buy enough hardware to properly test your software,
: why bother with testing at all?

Don't be silly. All test environments are deficient in some way or
another. It's called cost. And practicality. It is wholly useless to
argue that one should have extra hardware to test an error condition
when it is entirely possible and extremely easy to simulate the error
condition using software.

Tell me, does your testing environment include hardware that you can
do things to like smoking chips to see if the OS will recover from the
induced parity errors? How about an alpha-hit generator? A disk that
is partly defective? An OS that crashes randomly? A user that enjoys
destroying keyboards while your program is running?

I thought not.

Why did you make such an irrelevant, and nasty, statement?

Note that followups have been directed to alt.flame.

---
Bill                            { uunet | novavax } !twwells!bill



More information about the Comp.bugs.sys5 mailing list