From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5908 invoked from network); 1 Jan 2022 03:37:23 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 1 Jan 2022 03:37:23 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id AD4D29D04E; Sat, 1 Jan 2022 13:37:21 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 69C3D9CF51; Sat, 1 Jan 2022 13:37:10 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=algebras-org.20210112.gappssmtp.com header.i=@algebras-org.20210112.gappssmtp.com header.b="IDejat/Y"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id DE0499CF51; Sat, 1 Jan 2022 13:37:06 +1000 (AEST) Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) by minnie.tuhs.org (Postfix) with ESMTPS id 57F869CF06 for ; Sat, 1 Jan 2022 13:37:05 +1000 (AEST) Received: by mail-lj1-f171.google.com with SMTP id q8so31529358ljp.9 for ; Fri, 31 Dec 2021 19:37:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VicVbYghrollxqn3yolrxxCTl2DWQueca1dg3ZvaQ2I=; b=IDejat/YbiW7FeKFegY3DDskFzWhrRiLruQClz69C3Gxv75r5KjgViNOuKycFskUe+ Amf2dmGhCFw6fF30NIQldqVtMwSlSH7Gio0niLm3I9RcxPz/wDM7yh/eSEvaz/i4H2Fs cd3T0Jk03NSLb+OVrQtxrYh0IlagmYmBH+1HK+7FFdc3QQ6jnAnjeJTgeEsxoBzD+hRp +EmbEXx3PBAGIMT5VYkQRJtNLJXASVU/4oTrZA6OUXmORfZdGGHmV4HrELRdNOTqc0O8 ZEn8Fx1m87WqYAHRNghvg4dJo+sIRCikjXkPPnEb+N2cVUv7uEJObcW255qlrc7F+qWi Jc2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VicVbYghrollxqn3yolrxxCTl2DWQueca1dg3ZvaQ2I=; b=oUtxNTYDkTWgF8JxfIrYn5xDZDuJno7labHutH7rHSpdUGOPWQ5zZNVwTaveFHNJ3b l83XF+v7CBckIkTGykV66ZlhMOlCzWnKHCdONfW9QGHYVb45E4ummRfBu5lPnaml0ypW 4ayMP1ir/BXJMHnNlfdfP2QKieUY9u3CePdguNWULAoPj58ghWWe3r5fslQGuoO3QYJz SD4zaxbfxfsuoiVW9cJrWgPQvjmkJvzetOQZZKiFRlJ2uZeAhYho7GUj0KisUrNl4m+8 quU8vO8KsmYJALLNxb9EyBRYQx3PEowHNPJrpw9xhva1OwWvTIDYhpk1K+rRq6VVPD9y tt5Q== X-Gm-Message-State: AOAM533AZ/LNx43/bAExKDtKAfcaFdnAG/50e60kgLkzXQ1oFRyn2sgu RDw378mqoA81j0OjUr2fl4S+9VoTHkEpQRyrw1TNKkY+FIs= X-Google-Smtp-Source: ABdhPJynSbvgN2T5FFJrKOmxRotYjI5OMcU7QZbMAS2ZimF8SJphIvsFNap2f/vGeJ0KXafIemcdW55vvFkI91kdwJQ= X-Received: by 2002:a2e:b710:: with SMTP id j16mr31035132ljo.460.1641008223642; Fri, 31 Dec 2021 19:37:03 -0800 (PST) MIME-Version: 1.0 References: <28153.1641007110@cesium.clock.org> In-Reply-To: <28153.1641007110@cesium.clock.org> From: George Michaelson Date: Sat, 1 Jan 2022 13:36:52 +1000 Message-ID: To: "Erik E. Fair" Content-Type: multipart/alternative; boundary="0000000000003e7a5c05d47d0097" Subject: Re: [TUHS] v7 /etc/ttys and /usr/adm/wtmp shenanigans X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tuhs main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000003e7a5c05d47d0097 Content-Type: text/plain; charset="UTF-8" It was bad luck if the process holding your file open was an unkillable zombie. Reboot and clri fixes all things. Okay maybe "fix" isn't the word I want... On Sat, 1 Jan 2022, 1:27 pm Erik E. Fair, wrote: > Classically, files don't get de-allocated (their blocks re-added to the > filesystem free list) until the last open reference to their inode is > removed, even if the file name is removed from all directories. > > This behavior is commonly used for temporary files: open(2) with O_CREAT > and unlink(2), and file disappears when the file descriptor is finally > closed or the process exits without explicitly closing the descriptor (the > kernel will close all descriptors associated with an exiting process). > > Where process accounting is concerned, the kernel itself holds the inode > reference until it is explictly told to turn off process accounting. See > acct(2). > > Erik Fair > --0000000000003e7a5c05d47d0097 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It was bad luck if the process holding = your file open was an unkillable zombie. Reboot and clri fixes all things. = Okay maybe "fix" isn't the word I want...

On Sat, 1 Jan 2022, = 1:27 pm Erik E. Fair, <fair-tuhs@netbsd.org> wrote:
Classically, files don't get de-allocated = (their blocks re-added to the filesystem free list) until the last open ref= erence to their inode is removed, even if the file name is removed from all= directories.

This behavior is commonly used for temporary files: open(2) with O_CREAT an= d unlink(2), and file disappears when the file descriptor is finally closed= or the process exits without explicitly closing the descriptor (the kernel= will close all descriptors associated with an exiting process).

Where process accounting is concerned, the kernel itself holds the inode re= ference until it is explictly told to turn off process accounting. See acct= (2).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Erik Fair
--0000000000003e7a5c05d47d0097--