On Wednesday 27 August 2008 10:19:40 am Gary Jennejohn wrote: > On Wed, 27 Aug 2008 12:50:17 +0100 (BST) > Robert Watson <rwatson_at_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. The new pts entries are after all the 256 pty entries in /etc/ttys, so utmp may be larger becuase the pts entries are "later" in the file (higher offsets). However, if the file is sparse, then it doesn't actually hurt anything. -- John BaldwinReceived on Fri Aug 29 2008 - 17:12:33 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:34 UTC