From owner-freebsd-bugs@freebsd.org Wed Apr 22 20:46:00 2020 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2E2902C0FE6 for ; Wed, 22 Apr 2020 20:46:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 496ssN0W6zz3JRq for ; Wed, 22 Apr 2020 20:46:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 0F9452C0FE5; Wed, 22 Apr 2020 20:46:00 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0DB462C0FE4 for ; Wed, 22 Apr 2020 20:46:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 496ssM6gL1z3JRp for ; Wed, 22 Apr 2020 20:45:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id E05EF20C31 for ; Wed, 22 Apr 2020 20:45:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 03MKjxtk033123 for ; Wed, 22 Apr 2020 20:45:59 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 03MKjxUc033122 for bugs@FreeBSD.org; Wed, 22 Apr 2020 20:45:59 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 245765] inetd doesn't cleanup his PID file Date: Wed, 22 Apr 2020 20:45:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: jah@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 20:46:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D245765 Jason A. Harmening changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jah@FreeBSD.org --- Comment #1 from Jason A. Harmening --- It's not just inetd that exhibits this behavior, you'll see the same thing = for example with ntpd. However, I don't think this is necessarily a functional issue. inetd/ntpd w= ill not fail to restart if a prior pidfile is still present, they will simply update the pidfile to reflect the new process. Furthermore, stopping these services will not kill an innocent process: rc.subr(8) will not terminate t= he process if ps(1) indicates the PID from the pidfile does not correspond to = the expected executable. The general philosophy seems to be that rc.subr will make use of a pidfile = if one is present, but the creation and management of that pidfile is left up = to the individual daemon. For example, daemons that use pidfile(3) generally = seem to remove the pidfile on termination, because pidfile_open() automatically locks the pidfile which makes this safe to do. On the other hand, daemons that don't remove the pidfile also will not fail if the file is already present. As such, it also isn't appropriate for rc.subr to automatically remove the pidfile on service termination, as that could break pidfile lock= s or interfere with concurrent startup of a new instance of the service. --=20 You are receiving this mail because: You are the assignee for the bug.=