From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2542 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Jeff Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: s6 style "readiness notification" with perpd Date: Fri, 26 Apr 2019 17:58:56 +0200 Message-ID: <3257791556294336@iva5-e99a26c42780.qloud-c.yandex.net> References: <1122921556241940@sas1-d856b3d759c7.qloud-c.yandex.net> <3049721556290911@iva7-6548a8037c6d.qloud-c.yandex.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="87938"; mail-complaints-to="usenet@blaine.gmane.org" To: supervision Original-X-From: supervision-return-2132-gcsg-supervision=m.gmane.org@list.skarnet.org Fri Apr 26 17:59:00 2019 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hK3Fb-000Mk7-8L for gcsg-supervision@m.gmane.org; Fri, 26 Apr 2019 17:58:59 +0200 Original-Received: (qmail 13699 invoked by uid 89); 26 Apr 2019 15:59:24 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 13685 invoked from network); 26 Apr 2019 15:59:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1556294336; bh=e3pfsunyJeoj9SVACFAnzmV9ts8cXQVwVG1L1yx9uWI=; h=References:Date:Message-Id:Subject:In-Reply-To:To:From; b=tOmz54Msd7jiIiBQ6nkSeOAhkefv9+gdn+PKMMwjO84zBxZkkQkys/RE24zCnFXlu B3bOG1KY37fQ4AsQVPholU9qNNkzfejlanTLvVZRWL36dYmRe7+mFSdW4pOWVHfH8y DtLRdgQ718DupulGuBr1g5CcZLm4vOcLU+0RKrC0= Authentication-Results: mxback10g.mail.yandex.net; dkim=pass header.i=@yandex.com In-Reply-To: X-Mailer: Yamail [ http://yandex.ru ] 5.0 Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2542 Archived-At: 26.04.2019, 17:27, "Laurent Bercot" : > It doesn't matter what the number is that the service sees. As long > as perpd creates a separate pipe for every service (which is why it > would count against the maximum number of services it can maintain), > it can read the notifications from every service separately. so there is a small advantage of using an intermediary supervise child process instead of doing it in a more integrated way directly in the perpd parent process. of course one can run more intances of perpd on different scandirs should the upper limit on the number of open fds be exceeded (which is rarely the case i guess). > The notification-fd value used by s6-supervise is not relevant to > s6-supervise, it's only relevant to the service. It's only used > by s6-supervise at ./run spawning time, to tell what number the > *child* should dup2() the notification pipe to before execing ./run, > so the pipe is made available to the service on the fd it expects. probably fd 3 in most cases ... > The supervisor itself does not use fixed fd numbers. It would be > the same with perpd. ok, i see. so the perpd parent process opens a pipe(2) for every such service and does a dup(2) after fork(2) in the child process that execs into the service run script somehow among these lines: ... pid_t p = 0 ; int p [ 2 ] = { -1 } ; pipe ( p ) ; p = fork () if ( 0 == p ) { // child process that should execve(2) into the daemon ... dup2 ( p [ 1 ], requested_fd ) ; ... // exec into service run script execve ( ... ) ; _exit ( 111 ) ; } else if ( 0 < p ) { // parent process (perpd) // waitpid() for child and read(2) from p [ 0 ] } else if ( 0 > p ) { // fork(2) failed } ... dumb question anyway, my error.