From nobody Mon Dec 26 18:28:20 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 4NgmWM3Hxyz1HKBc for ; Mon, 26 Dec 2022 18:28:31 +0000 (UTC) (envelope-from mail@souji-thenria.net) Received: from alisa.souji-thenria.net (alisa.souji-thenria.net [188.68.37.165]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NgmWL6QhHz3hTd for ; Mon, 26 Dec 2022 18:28:30 +0000 (UTC) (envelope-from mail@souji-thenria.net) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=souji-thenria.net; s=20220813rsa; t=1672079302; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mgX8KQ2STzm6l55WZ+yq4QLBUTh7LrY0VQHUCD+k82s=; b=cPHRer7Xnn8Fj2aD50/2XTrA8fNrL2Wakm5vMWRXhaGBtZzf4jzfm3NIH/LV62EIwxf1LX P4nvAyWugelnc7Rfj9iFz1ZXwbIL9Bw25Q5DlGUhiYyP4uZNZKYOLn3MMmy/rrxB61fguR ejS4j924DL/xQduvQzP0EFG0Lto7lE8tu1H/IN4TPvx+FVlEM8SujoN0yHJ7cnQiuktyxV zyDUUy1GMTKKdfnNTJPlHg/sIBzD54UC1kJTkkQ0g3hZauORat1q6z6DJHp0w+qvzATaHz BCzWsSFEkrWUuMbQGwm1f5iBXtJ5Dp0GamLaLrn1h5wBq+A9rnNUxNPfUhI3Mg== Received: from [192.168.178.41] (nat-178-19-228-9.net.encoline.de [178.19.228.9]) by alisa.souji-thenria.net (OpenSMTPD) with ESMTPSA id 9c72f492 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 26 Dec 2022 19:28:21 +0100 (CET) Message-ID: <23fba5e2-0f7d-b609-9ec0-009d6f6bd085@souji-thenria.net> Date: Mon, 26 Dec 2022 19:28:20 +0100 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 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: daemon(8) exit behavior Content-Language: en-US To: Nathan Huff , freebsd-hackers@freebsd.org References: <86tu1i6q2s.fsf@enyo.nrhuff.com> From: Souji Thenria In-Reply-To: <86tu1i6q2s.fsf@enyo.nrhuff.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4NgmWL6QhHz3hTd X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:197540, ipnet:188.68.32.0/20, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 12/26/22 18:18, Nathan Huff wrote: > > 1. Is there any interest in upstreaming this? > Because I run in to this problem as well in the past, I would be most interested in this. > 2. What should happen if the supervised process doesn't exit after the > KILL signal is sent? Something has probably gone sideways somewhere if > we end up here, but I have definitely seen cases where something is > stuck with signals blocked. Currently my modification waits for the > process to actually exit possibly indefinitely. I chose that because I > don't think we should clean up PID files if the process is in fact still > running, but I can see wanting the daemon process to exit even if the > supervised process is still running as that is the current behavior and > still the behavior if a shutdown delay is not specified in my modified > version. > I think using the timeout limit which is used by FreeBSD when shutting down the system, makes the most sens and would have some consistency throughout the system, at leas in my opinion. Moreover, I think you should clean up the pidfile, if the daemon process created it. IIRC that's also the current behavior. -- Souji Thenria