From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2904 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Guillermo Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: runit SIGPWR support Date: Tue, 25 Feb 2020 15:38:15 -0300 Message-ID: References: <20200131043919.GF12551@cathexis.xen.prgmr.com> <20200214131544.tcvmh7tqu4hu2gul@caspervector> <1f198ed8-3682-26cd-e8d5-2efc412afde2@gmx.com> <18110531581952419@sas8-7ec005b03c91.qloud-c.yandex.net> <7003111582476686@vla3-6a5326aeb4ee.qloud-c.yandex.net> <00e1ad14-3bd4-c9ec-8f18-a33a1ba37bb6@NTLWorld.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="98742"; mail-complaints-to="usenet@ciao.gmane.io" To: supervision Original-X-From: supervision-return-2493-gcsg-supervision=m.gmane-mx.org@list.skarnet.org Tue Feb 25 19:38:34 2020 Return-path: Envelope-to: gcsg-supervision@m.gmane-mx.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by ciao.gmane.io with smtp (Exim 4.92) (envelope-from ) id 1j6f6I-000PQ3-La for gcsg-supervision@m.gmane-mx.org; Tue, 25 Feb 2020 19:38:34 +0100 Original-Received: (qmail 32115 invoked by uid 89); 25 Feb 2020 18:38:54 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Original-Received: (qmail 32108 invoked from network); 25 Feb 2020 18:38:53 -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=pun4Of48O9VPxD1hg93LstF4fwszhLph0LoJI/UVoXk=; b=H/Zct6HKFPOBdc8fVtzSQJbj3Uqww50uwSlBBV0EF9w6FGr7kdaqtIeQ7DPkIYsI+x MmCRacTvhgMRTqQbIx/vCsp972ov8mALm471Xgd5A/FyAjhn0bTrJDYGcATKIvvvxJU0 1aqoOAP/ccpoValtmroC2ODZeqqXzDoStjRjZ+s1+0p0JBPJadLccqIHD2crgj4/TEqT VCrcmCQyKXkhKlz+mjd6lOW+lJ6t8pyTJbj6ECy+ImeqpCJG94UJmU8GxcYTldq+RBRX zUDYGiarTEI8ZaAlB8WDMZqbNNMRjK0t1zKQ3EIHpUuUQyvaMfYSgJb7Ghc/KNgb3ByI XrkQ== 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=pun4Of48O9VPxD1hg93LstF4fwszhLph0LoJI/UVoXk=; b=i6s5zcrIvQTj2r4oyDY2m2lvX1Agn6GXsfLvwMMTnhpXZN8VMEoLiU7yIwXk5I6iNa /fw69CfFYdHy5KKk/5pS9g+6XbsWfhgN6gdC2CTIZZpCqh8VcMJvQgtkktAdgWrxJu8n OQGuiwj+X+M4ntCkseV/vG3goXBzqlRLRfLOuGrAmqOoYTYwuXqBhjC8cTXu0IaZTux6 ZYigJ8x5Spx7YqWMZSHKAgJ5LReR32HkWOi81EIB2vxSbabG7H3WWAaQWdO9Z+W6GVQG tHClryS9BQoamCstI5IDxmrhf7jiGDxjG0LHCfMq6EmH2YzA7oXtTtQGsZ9or0KPa2Cs 5H3Q== X-Gm-Message-State: APjAAAXZx6J4jm9KhjYc5HY5l9yDksJPyyGCzs3c51XSDZJHi32uzNLS 67QOjIrcsLRy/eROE3y5bzOt7FfsTxpk3dzjjiNetQ== X-Google-Smtp-Source: APXvYqxjc12dPNRxHFtGdp7cdqzbMlnCkGgwP/laWxRHTBnI7WWuuxdfJ4W01lxOc9SaPfljY9q/1FK7RfC4JJvOZOE= X-Received: by 2002:a5d:970e:: with SMTP id h14mr327885iol.201.1582655903772; Tue, 25 Feb 2020 10:38:23 -0800 (PST) In-Reply-To: <00e1ad14-3bd4-c9ec-8f18-a33a1ba37bb6@NTLWorld.COM> Xref: news.gmane.io gmane.comp.sysutils.supervision.general:2904 Archived-At: El mar., 25 feb. 2020 a las 6:08, Jonathan de Boyne Pollard escribi=C3=B3: > > Laurent Bercot: > > Of course, but once the fd is closed, /dev/console should not have > > any impact on the process, so would a kbrequest still reach it? > > Yes. Also, I tested it :) I added an open2("/dev/tty0", O_RDONLY | O_NOCTTY) + ioctl() + fd_close() sequence to s6-linux-init.c right after the reboot(RB_DISABLE_CAD) call, specifying SIGQUIT as the argument of the KDSIGACCEPT ioctl (to use a signal 'divertable' by s6-2.9.0.1's s6-svscan), and the SIGQUIT handler does get called indeed when I press Alt + Up Arrow. The file descriptor specified in the ioctl() call, as far as I can tell, is only used by the kernel to check permissions. The ioctl is allowed if the FD corresponds to the process' control terminal, or if the process has CAP_KILL or CAP_SYS_TTY_CONFIG capabilities. But the kernel just seems to record the PID of the invoking process and the requested signal number. (vt_ioctl() in drivers/tty/vt/vt_ioctl.c). > First: This is a kernel virtual terminal thing not a console > thing. Strictly speaking, it is doing it wrongly to access it through > the console device, which is not necessarily a KVT. Yeah, I overlooked this. I suppose it'll work on /dev/console as long as it is a kernel virtual terminal, but it won't always be the case. sysvinit and systemd use /dev/tty0 for the ioctl (and sysvinit falls back to its standard input if that fails), so I used that for the (second) test. G.