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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15049 invoked from network); 3 Dec 2020 19:56:20 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 3 Dec 2020 19:56:20 -0000 Received: (qmail 22603 invoked by uid 89); 3 Dec 2020 19:56:43 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 22596 invoked from network); 3 Dec 2020 19:56:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=vVWgylLd7Av5Ua78vubgAFQvOoAc6338yNjxPT1dTOs=; b=dDbl5rpAOigEsJyD4AwU9uZgVcQ0TkAQu07MZNkWoKL0p9fdcTLyBoDB7G7JFV8gc0 FlamJllsJu589mpx1qX44Zue34A+UzXn5cUI/ytTHhF4sBRrpL1eL1sd+eCOHY/sJloh z7oOHqIrKNa3p4IhfTXCTDvrowcCOCjjQIIjFtAi9hc2V4TgmqnvvuWyu1UjW6HxdhjW nE7wx57H6sqPA5NjGFlQYmedSnbpBMB0e7WLGX5Df0yeiYuLJUmFozYVxPb9bBnc6emc MGHpvcOkxFAxpW3NMTQiwibnDhudzMIDgAr9+aug1B7i5RZ10aXTiG5fQzfiihwA31gX Ef0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=vVWgylLd7Av5Ua78vubgAFQvOoAc6338yNjxPT1dTOs=; b=NJNK+tprzbSbZvNRpmk0MgCFp4W7deJeugnPAj6Z8jN4pqKuEGPrdywA8QeHMlZHDM Ul1ULbYndOh480Le26q8Y2wcXu8CVp1DGQsFLv7+DMoHYHnjTMTQTY5OygcdqUatn7t5 /iyHFP7JX5Leb2zDTTwMs94up3yNuzSaQtQ/8PHH5JNiwRTyTn9s0I/RIo2UDD1djAA3 8g0sK2Xmzt7MLpT3XDNgPQhhT4X1V1HLeKagiqjl4v0tC/vzymVKaylDJOu9uqwKo/Xn UX2dEM0Xb/zELqnozC7Tgr4O7WQPCB9X5+GRg0Hksv0/dL3sdqqu7CAim385pJ5eNnMr QsfA== X-Gm-Message-State: AOAM530cEeslCtajBSa7BNWj0z5zGChsZ9Ox1lk1+YfRRzmuwLcsDuVu BGryzpvfcwXjq8hZkA2p/SMufhoHGDq4rTDtZ+mj5iUe5M8= X-Google-Smtp-Source: ABdhPJw0gJ5Ign/2YeV1d2Pqv6FhNMhD35wFCm+xMcF2/hMzjtptuajzuTE00dLDNKsMUY2EryCHUDWoI32JVdbPCKU= X-Received: by 2002:a02:c8c7:: with SMTP id q7mr877546jao.7.1607025375375; Thu, 03 Dec 2020 11:56:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Guillermo Date: Thu, 3 Dec 2020 16:56:06 -0300 Message-ID: Subject: Re: s6-supervise: use of nosetsid To: "supervision@list.skarnet.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable El jue, 3 dic 2020 a las 13:47, Laurent Bercot escribi=C3=B3: > > I have previously added the "nosetsid" feature to s6-supervise, to > address the issue: [...]. So when people want to manually > test a supervision tree, they can have nosetsid files in their test > service directories, and ^C will send a SIGINT to all the processes > including the services, so everything will die, which is what they > want. > [...] > Hence, my question to users: do you have a *valid* reason to use > nosetsid files in your service directories? I don't know if it is a valid reason, so I'll just tell what I remember using these files for, and you judge :) I happen to be one of those people who test service directories and s6-rc service definitions by running s6-svscan in a terminal using 's6-svscan &' (and then s6-rc-init with a live state directory that is not /run/s6-rc, and lots of -l options), and tearing down the supervision tree using 's6-svscanctl -t .'. So no Ctrl + C in my case. I remember occasionally using 'nosetsid' files for the convenience of being able to redirect the output of 'run' and 'finish' to /dev/tty (the controlling terminal of the shell I used to run s6-svscan) so that I could see certain messages during tests in which s6-svscan had its stdout & stderr redirected to a logger (typically, for emulating an s6-linux-init-like s6-svscan-as-process-1 scenario). I think it was for doing something like foreground { redirfd -w 1 /dev/tty echo "Some message I want displayed on my terminal" } Having the supervised processes become session leaders meant that they lost the controlling terminal, which, for X terminals, would be some random special file in the devpts filesystem. Redirecting to /dev/tty would not work in that case. Granted, it is a rather obscure usage, and not a frequent one in my case, but your mentioning of notsetsid files triggered the memory, so I thought I'd mention that. G.