supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: "Laurent Bercot" <>
Subject: Re: Trouble starting services on boot with s6-rc
Date: Sat, 20 Aug 2022 12:57:46 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

>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 
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

  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- -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] 
If your real service needs it, you can disable the timeout by adding to
your Dockerfile:
or you can adjust it to a bigger value than 5000.

  Good luck,



  reply	other threads:[~2022-08-20 12:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-20 11:01 dark.pen9108
2022-08-20 12:57 ` Laurent Bercot [this message]
2022-08-20 14:30   ` dark.pen9108
2022-08-20 14:58     ` Laurent Bercot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).