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=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FROM,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10425 invoked from network); 20 Aug 2022 14:31:42 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 20 Aug 2022 14:31:42 -0000 Received: (qmail 10791 invoked by uid 89); 20 Aug 2022 14:32:07 -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 10784 invoked from network); 20 Aug 2022 14:32:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1661005895; x=1661092295; bh=Nd5AFgqsKM JXS1opZ2EousGZ+N1JDb+dSZcWO28OWE4=; b=a+O/2FLnRtSUQJ3eOd7yRIr0y6 qyYjQnPRYyX05G/g/RB9yJFC5InZk8ah1Wc9526pBrdpo/80WQ/UZxmnDBKQW9k+ 3PDCse706unmOt1Le/AR/t0DQDWWmDvMMVjyDzZ1po6/8CZsOgq1jxUA6kXvogd+ cPWdgGMFiVh4eKcDZ5iZujm+TgBkhdAXUNjucf8ZEzwo6rey3bgUHCwaG4LwoF+g EeQ27La11mXh3I5zG/T5f5SY/HFfIMnafqTD0CYamgTLbdMqIOS4zOw4eUwWQHy5 /APIirhiKmjShE+L7ldNf/Sc00CXxT8DunzAtZYXKnRhSpd+ajHSaDFFtERQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1661005895; x=1661092295; bh=Nd5AFgqsKMJXS1opZ2EousGZ+N1J Db+dSZcWO28OWE4=; b=LZa7LkHD2zN2zT73iKI4Uef5hNNAowiTdOQzL49SdL4s EB6Y1SBi3hAg3ngHI5zSWVYWStKTlCaLmw9nlei0xNSsUfJaBLvsm1wUwTwmyjAN ttrDKPahGqN1R2bEgAwM3OplIJX3UzOmtGlVGt4sXisp7qdgRSGm2E/FhSUCNB9F aUeVAgoD4fL9hNNSme+doNqZEhMLa3tM+A86htbpfd7huDRMfiw28HPFQCiMHSaU EdI2fKHC+K6UAV1Jps6PvSXLAT3iK9T7pQ+o+IP7ZDOPiQAh9OXi6QpJnfw9Mmde uh44GKVBz02l0VpDasSSjS1JvXqOoC1qGrqmvUG+XQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdeifedgjeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpegurghrkhdrphgvnheluddtkeesfhgrshhtmhgrihhlrdgt ohhmnecuggftrfgrthhtvghrnhepheektdevleethfehjeeludduffetgfevgeelkefghe fgvdfggefhkefhgfejledunecuffhomhgrihhnpehgvghnthhoohdrohhrghdpghhithhh uhgsrdgtohhmpdhrvggrughmvgdrmhgupdhmohhvihhnghdqthhoqdhvfedrmhgunecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepuggrrhhkrdhp vghnledutdeksehfrghsthhmrghilhdrtghomh X-ME-Proxy: Feedback-ID: i9299460b:Fastmail X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-841-g7899e99a45-fm-20220811.002-g7899e99a Mime-Version: 1.0 Message-Id: In-Reply-To: References: <18dc7efd-9ce3-4350-b051-49c047e32e7a@www.fastmail.com> Date: Sat, 20 Aug 2022 10:30:30 -0400 From: dark.pen9108@fastmail.com To: supervision@list.skarnet.org Subject: Re: Trouble starting services on boot with s6-rc Content-Type: multipart/alternative; boundary=58ae774b841347d3875984dae131cb4a --58ae774b841347d3875984dae131cb4a Content-Type: text/plain > >> root 34 0.0 0.0 192 52 pts/0 S+ 18:53 0:00 /package/admin/s6-2.11.1.0/command/s6-sudoc -e -t 30000 -T 4999 -- up 3 > > The "-T 4999" part means there's a 5 second timeout on running your > sleeponstart service. And since this service is waiting for 30 seconds > before succeeding, and 30 > 5... it means that it times out after 5 > seconds and gets killed, so the transition fails, and longrun_test > (which depends on it) is never brought up. > > s6-overlay-specific section: > > - You should see all that happening in your container's logs - s6-rc > prints informative messages when something fails. Unless you have > changed the S6_VERBOSITY value from the default 2 to something lower. > > - The 5 seconds timeout likely comes from the fact that you have not > modified the S6_CMD_WAIT_FOR_SERVICES_MAXTIME value, which is 5000 by > default. As is written in both the README[1] and the migration guide[2] > :P > If your real service needs it, you can disable the timeout by adding to > your Dockerfile: > ENV S6_CMD_WAIT_FOR_SERVICES_MAXTIME=0 > or you can adjust it to a bigger value than 5000. ahh, very obvious. Sorry, I did read the docs(quite a few times) but starting from zero it was quite a lot to grok and I overlooked this(and I'm sure a number of other things). After adjusting S6_CMD_WAIT_FOR_SERVICES_MAXTIME, things are working as expected. I am a bit ashamed to admit I cannot find the logs. From reading https://wiki.gentoo.org/wiki/S6_and_s6-rc-based_init_system#logger I thought maybe I should be looking for file /run/uncaught-logs but could not find any such file in my docker instance(I understand, docker is not Gentoo). While the docs did speak a lot to the directory structure used by s6, I still am finding it quite hard to figure out what the default directories are for some things. (e.g. I was clear on where my uncompiled s6-rc service directories should go but they seemed to "magically" get complied on boot and show up in a scan_dir) One additional item. As seems like not a great idea to smash the timeout for all services. Is there any way to adjust it on a per service basis? If not consider me a +1 to kindly add it to a wishlist somewhere. Thanx so much for the quick reply, help, and great free software! n.b. You should put up a BTC lightning "tip bucket" somewhere :) -Benjamin On Sat, Aug 20, 2022, at 8:57 AM, Laurent Bercot wrote: > >Hoping this is the right place to ask for some help as I am very new to s6 and not well versed on any init system. > > s6-overlay questions are normally asked in the "Issues" section of the > s6-overlay GitHub repository, but since yours are really s6-rc > questions, > it's fine :) (even though the answers are related to s6-overlay!) > > > >I can see that my services are registered with s6-rc > >[Aug 19 18:43:04 root@s6 ~]# s6-rc-db list all | grep -e longrun_test -e sleeponstart > >sleeponstart > >longrun_test > > That proves your services are *in the database*, not that they're going > to get started. To make sure your services are started on boot, you > should also check that they're declared in the "user" bundle (that's > the bundle where users declare what services are part of the final > machine state, by s6-overlay policy). > > $ s6-rc-db contents user | grep -e longrun_test -e sleeponstart > > But since they *are* started when you boot your container, it means > they're indeed declared there, so that's not the issue. The real issue > is here: > > >root 34 0.0 0.0 192 52 pts/0 S+ 18:53 0:00 /package/admin/s6-2.11.1.0/command/s6-sudoc -e -t 30000 -T 4999 -- up 3 > > The "-T 4999" part means there's a 5 second timeout on running your > sleeponstart service. And since this service is waiting for 30 seconds > before succeeding, and 30 > 5... it means that it times out after 5 > seconds and gets killed, so the transition fails, and longrun_test > (which depends on it) is never brought up. > > s6-overlay-specific section: > > - You should see all that happening in your container's logs - s6-rc > prints informative messages when something fails. Unless you have > changed the S6_VERBOSITY value from the default 2 to something lower. > > - The 5 seconds timeout likely comes from the fact that you have not > modified the S6_CMD_WAIT_FOR_SERVICES_MAXTIME value, which is 5000 by > default. As is written in both the README[1] and the migration guide[2] > :P > If your real service needs it, you can disable the timeout by adding to > your Dockerfile: > ENV S6_CMD_WAIT_FOR_SERVICES_MAXTIME=0 > or you can adjust it to a bigger value than 5000. > > Good luck, > > -- > Laurent > > > [1]: https://github.com/just-containers/s6-overlay/blob/master/README.md > [2]: > https://github.com/just-containers/s6-overlay/blob/master/MOVING-TO-V3.md > > --58ae774b841347d3875984dae131cb4a--