Date: Wed, 27 Aug 2008 16:19:40 +0200 From: Gary Jennejohn <gary.jennejohn@freenet.de> To: freebsd-current@freebsd.org Subject: Re: Enormous utmp since mpsafetty Message-ID: <20080827161940.1b4403ee@peedub.jennejohn.org> In-Reply-To: <alpine.BSF.1.10.0808271248200.96701@fledge.watson.org> References: <20080826124335.GD3305@carrot.paeps.cx> <48B416E7.70905@163.com> <20080827091255.GH3305@carrot.paeps.cx> <20080827132141.593e728d@peedub.jennejohn.org> <20080827114623.GA52927@keltia.freenix.fr> <alpine.BSF.1.10.0808271248200.96701@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 Aug 2008 12:50:17 +0100 (BST) Robert Watson <rwatson@FreeBSD.org> wrote: > On Wed, 27 Aug 2008, Ollivier Robert wrote: > > > According to Gary Jennejohn: > >> There are many more pseudo-ttys in /etc/ttys now. AFAIK utmp allocates an > >> entry for every one of them at startup. > > > > utmp concepts are ancient. It is indexed by the tty/pty number so can grow > > rather large but it should be a sparse one too. I remember talks about > > replacing it with something a bit more modern. Backward compatibility is > > assured through login(3) although it would break programs digging in the > > utmp file itself. SVR4 had utmp/utmpx and setutline/getutline BTW... > > Right -- utmp growing to 256K would be an excellent example of utmp format > inefficiency. On the other hand, utmp growing to 998M is probably an example > of a bug rather than an inefficient design. freefall.FreeBSD.org, a > relatively busy shell box, has a utmp of around 5k, so common use doesn't > generally exercise that inefficiency... > But freefall is running FreeBSD 7.0-STABLE #34: Sat Apr 12, so it doesn't have the new tty stuff running, although I don't suppose that completely explains the gigantic utmp which OT reported. --- Gary Jennejohn
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080827161940.1b4403ee>