From owner-freebsd-current Mon Oct 27 10:54:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA14507 for current-outgoing; Mon, 27 Oct 1997 10:54:01 -0800 (PST) (envelope-from owner-freebsd-current) Received: from lsd.relcom.eu.net (lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA14480 for ; Mon, 27 Oct 1997 10:53:51 -0800 (PST) (envelope-from ache@lsd.relcom.eu.net) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id VAA01222; Mon, 27 Oct 1997 21:53:24 +0300 (MSK) (envelope-from ache) Date: Mon, 27 Oct 1997 21:53:21 +0300 (MSK) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: Nate Williams cc: Mark Murray , current@freebsd.org Subject: Re: Inetd & login class bug (was Re: cvs commit: src/etc master.passwd) In-Reply-To: <199710271841.LAA01233@rocky.mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 27 Oct 1997, Nate Williams wrote: > [ Moved to -current from cvs-committers ] > > " fingerd uses up all the resources that Apache needs " No. Inetd assumes that nobody have some particular limits (which is against Mark nobody definition) and run fingerd with this limits. > > I am not sure, how to fix inetd at this time, maybe we need to handle > > nobody name specially (and use daemon limits in this case), or maybe > > just use daemon limits for _all_ entries in inetd.conf... > > Any ideas? > > I think that every new process spawned from inetd should have it's own > 'private' nobody limits, and not 'share' a set of limits for every > process spawned from inetd. Please explain, I not understand well what you say. Some time ago inetd runs all process with the limits it was started by rc, i.e. daemon class limits. Recently it was changed to take user field from inetd.conf and set this user limits (which is wrong for nobody case since we can't suppose some particular limits there). Right now I think checking for nobody name and set default daemon limits will be enough solution. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/