From nobody Mon Dec 26 17:34:51 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 4NglKh1Hp7z1HBY3 for ; Mon, 26 Dec 2022 17:35:04 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NglKg6bHkz3L6l for ; Mon, 26 Dec 2022 17:35:03 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vs1-f49.google.com with SMTP id 3so10695921vsq.7 for ; Mon, 26 Dec 2022 09:35:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=p6D18gtAkIv4BoyBsWNZKqOQJQdeZBU8SGArtq3Q6KA=; b=iQeRKARgLahm0HEk9Pnmag4KZ75LPKq2v8tYv0N5H3XQ9BHLufS+9D3tVPPaDwJPoq dltAaqFAUdSKfCfFqdhRSZf5u21GQjZdcgAhmGl9fSg/Q5Mo5nFbYatbniy9uh3j+ooj 4XhrXzC3L6hL6icVIeFVGeaoX7en1XaQ6nvAiGHgdkXGH9V0mg1pW6B+H/WH2NLn1p66 vh+s4GCMudOcAeiiWZxjJLLPiDMwOw1SLS1dDnKFR36uy4kRvBr4cGlkQ3YuXHr3kyDV yX1OSOmTHP1v13FMuGL7jTwTyLUb8FTkuYwrpYwXJ73Ft9hCajC6UbZtDlGwi3GcQGok O6mw== X-Gm-Message-State: AFqh2ko7vcoZ+GGBAytlPzUTra9bGtuq6+X8OlaurRG84LA0WVBwg9+l kLx+gcfs0PQKl/UAf4vSzLgbcPIDIAmT9ZgKA67Pypr2 X-Google-Smtp-Source: AMrXdXt5+RdU66ZB5AcslreV+r/BWXvSG3qd3aL53wn6O3V/fy4joURd/nzxMVePtU0oeode4ML6yNrr7DQev7l6yUo= X-Received: by 2002:a05:6102:3a63:b0:3b5:26e4:f191 with SMTP id bf3-20020a0561023a6300b003b526e4f191mr2256278vsb.53.1672076102687; Mon, 26 Dec 2022 09:35:02 -0800 (PST) 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 References: <86tu1i6q2s.fsf@enyo.nrhuff.com> In-Reply-To: <86tu1i6q2s.fsf@enyo.nrhuff.com> From: Alan Somers Date: Mon, 26 Dec 2022 10:34:51 -0700 Message-ID: Subject: Re: daemon(8) exit behavior To: Nathan Huff Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4NglKg6bHkz3L6l X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Mon, Dec 26, 2022 at 10:19 AM Nathan Huff wrote: > > > The current behavior for the daemon command when it receives the HUP > signal and it is supervising a process is to send a HUP signal to the > supervised process and then exit immediately. According to the source > comments this is the intended behavior. The issue I have run into with > this behavior is that when the daemon process is when writing the supervised > processes stdout/stderr to syslog or an output file you can lose any > log messages that the supervised process outputs during its shutdown > process. Do you mean SIGTERM instead of SIGHUP? > > I created a small modification to the daemon process that allows setting > a shutdown delay that will send HUP to the supervised process then > continues to read the process output for up to delay seconds and then > sends the supervised process the KILL signal. This allows a window for > the supervised process to gracefully shutdown and we can still log any > messages created during that time period. 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. > > A couple questions for the list. > > 1. Is there any interest in upstreaming 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. Waiting indefinitely is probably the best thing that we can do if a SIGKILLed process doesn't exit. > > -- > Nathan Huff >