rusty@GARNET.BERKELEY.EDU (rusty wright) (02/22/90)
The user limit (software license/login limit stuff) works in conjunction with the quota system. In other words nobody but root can login unless you have quotas turned on in your system config file. Essentially it's a botched design by the DEC people.
grr@cbmvax.commodore.com (George Robbins) (02/22/90)
In article <14200@reed.UUCP> kab@reed.UUCP (Kent Black) writes: > > Problem is building a custom kernel for Shiva. > First build was > maxusers 5 # conserving a little space > physmem 12 > no QUOTA > > This new kernel seems just fine except that it refuses to believe our > upgrade: in fact, it complains "Login limit reached" in the process of > booting multi-user, after which it allows one login and will not allow > root to su more than once. (Nothing, that I know of, remotely like > this in our BSD4.3 sources.) The login limit is somehow mediated by the quota code, so no QUOTA, no multi-user. This documented in somewhere or other, but it's so silly you wouldn't really expect it... > > Is this related to the gnode count, and if so, how?!? I have rerun > install_upgrade (apparently successfully, or so it says). Is there > any (other) reason for not increasing the gnode count arbitrarily? > (Perhaps the nfile count as well, since we ran up against that limit > in some extreme cases.) > > We do not need more process slots, ports, etc. and with only 8M of > memory, a few dozen saved bytes does help (well, not much ;-). No, it > is not worth the effort for the expected savings (3 minutes of editing > and compiling and two hours of hair pulling ;-), but my curiosity has > really gotten the better of me. Want to know what to expect when I > try to modify buffer cacheing and the like. Have fun, the real problem is estimating the real requirements for some of these resources so that you don't git bit at really bad moment. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
kab@reed.bitnet (Kent Black,L08,640,7754072) (02/22/90)
In article <14200@reed.UUCP> kab@reed.UUCP (Kent Black) writes: > >We* have 3100's, just upgraded to Ultrix v3.1/UWS 2.2. > First build was > maxusers 5 # conserving a little space > physmem 12 > no QUOTA Thanks for the helpful mail, problem is understood: Do not compile without QUOTA! mellon@decwrl.dec.com: "... without the QUOTA option, the quota() call to determine how many users can log in will return -1, since the quota system call isn't in the kernel anymore." Similar messages from rusty@garnet.berkeley.edu & farhad@tehran.stanford.edu so far, I assume more will come; forgive me if I do not thank you individually. I thought I had another kernel running without QUOTA and had ruled this out, but it turns out I had my own login(1) running there, which I had forgotten. Will DEC at least document this behaviour somewhere obvious (like conf/GENERIC) unless or until it gets fixed? Farhad suggested compiling with maxusers = 16. These systems already spend too much of there lives swapping processes, though, with only 12M of memory. For amusement I watch half a dozen processes swap (and seconds pass) before a new xterm will start. Anybody else trying to run 3100's with this little memory? (Vishnu has 24M and has a far happier life.) I am still interested in any info on ideal gnode limits -- should there always be some free, or do they get recycled; i.e., is NGNODES a hard limit as I think it is. We have seen one crash with "out of gnodes" and "file table full" panics; does this always cause a crash, or did I just get lucky? (We have several times noticed a paucity of gnodes, less than 5 available, so I assume that the limit has been hit a few times, but only one crash; I have since raised the count significantly.) Thank you all again, -- kab