From owner-freebsd-stable Fri Dec 19 10:19:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA05294 for stable-outgoing; Fri, 19 Dec 1997 10:19:49 -0800 (PST) (envelope-from owner-freebsd-stable) Received: from homer.duff-beer.com (mail@homer.duff-beer.com [194.207.51.241]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA05275 for ; Fri, 19 Dec 1997 10:19:43 -0800 (PST) (envelope-from scot@poptart.org) Received: from localhost (scot@localhost) by homer.duff-beer.com (8.8.5/8.8.5) with SMTP id SAA08782; Fri, 19 Dec 1997 18:18:50 GMT Date: Fri, 19 Dec 1997 18:18:49 +0000 (GMT) From: Scot Elliott To: Ian Freislich cc: stable@FreeBSD.ORG Subject: Re: fsck problem at boot time In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 19 Dec 1997, Ian Freislich wrote: > This problem relates to the resources allowed to the boot process, > run as user daemon - as I'm led to believe. Fscking a 16Gb disk > requires more memory than the kernel is willing to give to fsck. > The entry in /etc/login.conf for daemon hints that the limits set > here are used for rc. Changing the limits here, running cap_mkdb > and rebooting proved otherwise. The 2.2.2 system I recently installed didn't have a default login.conf - and everything works fine. I see that my new /usr/src/etc which I've since CVSupped, has one with these dodgy default settings in it. It does say at the top of the file that it's an *example*... and I rather think that it's bad news to use this without altering it yfour your own use first. I personally dislike the practice of setting CPU limits for users. There really seems very little point in putting a hard limit of CPU time on a process. This is especialy true for root and daemon - which are used to run system daemons which persist for the whole uptime of the machine. Any server that actually does anything would eventually be killed if it had a hard CPU limit set. Similarly, for login users, there seems very little point because any job which takes that much CPU time can just be split into multiple jobs taking less CPU time - hense using the same total resources and just inconvieniencing the user. It would make more sense to limit CPU resources as a percentage per day or hour. For instance, allocate daemon 25% CPU resources if you only want your server proceses to use a quarter of the machine's CPU. But then you have a problem of what to do when that limit's reached. To be honest Id suggest just staying away from limiting system users. It seems a whole lot simpler just to let them get on with what they do with no interference. Scot Elliott ----------------------------------------------------------------------------- Scot Elliott (scot@poptart.org) | Work: +44 (0)1344 899401 PGP fingerprint: FCAE9ED3A234FEB59F8C7F9DDD112D | Home: +44 (0)181 8961019 ----------------------------------------------------------------------------- Public key available by finger at: finger scot@poptart.org or at: http://www.poptart.org/pgpkey.html