From nobody Mon Dec 26 21:13:29 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NgrB755bnz1J0Ds for ; Mon, 26 Dec 2022 21:13:51 +0000 (UTC) (envelope-from nhuff@acm.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NgrB66MpRz46HR for ; Mon, 26 Dec 2022 21:13:50 +0000 (UTC) (envelope-from nhuff@acm.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="Y 0OZo9c"; spf=softfail (mx1.freebsd.org: 66.111.4.25 is neither permitted nor denied by domain of nhuff@acm.org) smtp.mailfrom=nhuff@acm.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=acm.org (policy=none) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6FADB5C0059 for ; Mon, 26 Dec 2022 16:13:50 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Mon, 26 Dec 2022 16:13:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1672089230; x= 1672175630; bh=DHDT/VrWNre1BFhNPcmue1QLZm0Wrmzi9pLxw4KbzUY=; b=Y 0OZo9cdPp/GqEKc61loqMrhTiSQ2KntPJqV+ikVr8VK7b4WOwXGVrNrcQ2uYBX9j QdBFbGZGGc6N4afl+Ue8w/hd7vR0u2LM56BsxglAz5swHrPOidznL9X6eWjACHyB oqsARtnpam+cTAwlm8Vc7/SqoL2iLm6E2Jq9y7JcLNUfFyo+IsvyPTfoItvTwAMV g4i7o8Ie5J65jaWk1DAMizpGwFWGg3PVb0x8GRtlDfkVQNj7dbimKvQC+TlTvCog 4vRNh1EfKZGSPTAPFHNjcTheNJhDuJKOB93OyPDVGyWwZ/hP3/fD5WkzgKabubwe zm7yPQOF2coXAT6h48Obw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrheekgddugeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfpfgrthhhrghnucfjuhhffhdfuceonhhhuhhffhesrggtmhdr ohhrgheqnecuggftrfgrthhtvghrnhepleduteffvdfgudeiledugeduhfelffevvdekle duiedvgfeujeekgefhuedtueefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhepnhhhuhhffhesrggtmhdrohhrgh X-ME-Proxy: Feedback-ID: ida914761:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 17E182D4007D; Mon, 26 Dec 2022 16:13:50 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1185-g841157300a-fm-20221208.002-g84115730 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 x-forwarded-message-id: <86r0wm6o7o.fsf@enyo.nrhuff.com> Message-Id: <679d90a3-2b6b-4b9d-ab75-44558d93f916@app.fastmail.com> Date: Mon, 26 Dec 2022 14:13:29 -0700 From: "Nathan Huff" To: freebsd-hackers@freebsd.org Subject: Fwd: Re: daemon(8) exit behavior Content-Type: multipart/alternative; boundary=8cf3b13f4f3447a0bf3fd6291bddccec X-Spamd-Result: default: False [-3.89 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[messagingengine.com:s=fm2]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[acm.org : No valid SPF, DKIM not aligned (relaxed),none]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.25:from]; XM_UA_NO_VERSION(0.01)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[messagingengine.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4NgrB66MpRz46HR X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --8cf3b13f4f3447a0bf3fd6291bddccec Content-Type: text/plain Alan Somers writes: > > Do you mean SIGTERM instead of SIGHUP? > Yes I meant SIGTERM not SIGHUP. > > Instead of delaying for a fixed number of seconds, what if daemon were > just to waitpid for the child after signaling it? That would prevent > a command like "service foo restart" from starting a new instance of > the daemon. But if the actual server process is still running, then > that behavior is probably desirable. > That is basically what my modification does. The delay really just sends SIGKILL to the supervised process after the delay and waits for it to die. The delay just gives the supervised process time to gracefully shutdown before trying to more aggressively kill it. > > Waiting indefinitely is probably the best thing that we can do if a > SIGKILLed process doesn't exit. > That is my opinion, but it isn't the current behavior so I figured others might have a different opinion. >> >> -- >> Nathan Huff >> --8cf3b13f4f3447a0bf3fd6291bddccec Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Alan Somers <= ;asomers@freebsd.org> writ= es:

>
> Do you mean SIGTERM instead of SIGHUP?
>

Yes I meant SIGTERM not SIGHUP.<= br>

>
> Instead of delaying= for a fixed number of seconds, what if daemon were
> j= ust to waitpid for the child after signaling it?  That would preven= t
> a command like "service foo restart" from starting = a new instance of
> the daemon.  But if the actual= server process is still running, then
> that behavior = is probably desirable.
>

T= hat is basically what my modification does.  The delay really just<= br>
sends SIGKILL to the supervised process after the delay an= d waits for it
to die. The delay just gives the supervised= process time to gracefully
shutdown before trying to more= aggressively kill it.

>
&= gt; Waiting indefinitely is probably the best thing that we can do if a<= br>
> SIGKILLed process doesn't exit.
>

That is my opinion, but it isn't the current = behavior so I figured
others might have a different opinio= n.

>>
>> --
>> Nathan Huff
>>

<= /div>

--8cf3b13f4f3447a0bf3fd6291bddccec--