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.0 required=5.0 tests=MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31987 invoked from network); 20 Aug 2022 12:57:49 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 20 Aug 2022 12:57:49 -0000 Received: (qmail 7129 invoked by uid 89); 20 Aug 2022 12:58:13 -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 7122 invoked from network); 20 Aug 2022 12:58:13 -0000 From: "Laurent Bercot" To: supervision@list.skarnet.org Subject: Re: Trouble starting services on boot with s6-rc Date: Sat, 20 Aug 2022 12:57:46 +0000 Message-Id: In-Reply-To: <18dc7efd-9ce3-4350-b051-49c047e32e7a@www.fastmail.com> References: <18dc7efd-9ce3-4350-b051-49c047e32e7a@www.fastmail.com> Reply-To: "Laurent Bercot" User-Agent: eM_Client/9.1.2109.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable >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=20 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 s= leeponstart >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 /packag= e/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]=20 :P If your real service needs it, you can disable the timeout by adding to your Dockerfile: ENV S6_CMD_WAIT_FOR_SERVICES_MAXTIME=3D0 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]:=20 https://github.com/just-containers/s6-overlay/blob/master/MOVING-TO-V3.md