Openrc/s6 integration issue

[damobrisbane]

ISSUE

I use Gentoo init/openrc and have been running docker containers some time under runlevel services but recently the functionality seems to have broken. Basic structure is:

# grep supervisor /etc/init.d/container.nexus
supervisor=s6
# 
# docker ps
CONTAINER ID   IMAGE                                      COMMAND                  CREATED        STATUS        PORTS     NAMES
cf611125e466   reg.ops:5000/strimzi/kafka-bridge:latest   "/opt/strimzi/bin/ka…"   8 hours ago    Up 8 hours              strimzi-bridge
dcf8e9f0bada   reg.ops:5000/traefik:xlatest               "/entrypoint.sh trae…"   8 hours ago    Up 8 hours              traefik
e7262831015d   reg.ops:5000/sonatype/nexus3               "/opt/sonatype/nexus…"   18 hours ago   Up 18 hours             nexus
# 
# /etc/init.d/container.nexus stop
container.nexus               | * Stopping container.nexus ...                                                                                                                                                                      [ ok ]
# 
# docker ps
CONTAINER ID   IMAGE                                      COMMAND                  CREATED       STATUS       PORTS     NAMES
cf611125e466   reg.ops:5000/strimzi/kafka-bridge:latest   "/opt/strimzi/bin/ka…"   8 hours ago   Up 8 hours             strimzi-bridge
dcf8e9f0bada   reg.ops:5000/traefik:xlatest               "/entrypoint.sh trae…"   8 hours ago   Up 8 hours             traefik
# 
# /etc/init.d/container.nexus start                                                                                                                                                                                                 [ ok ]
# 
# docker ps
CONTAINER ID   IMAGE                                      COMMAND                  CREATED         STATUS         PORTS     NAMES
7306942c0b47   reg.ops:5000/sonatype/nexus3               "/opt/sonatype/nexus…"   4 seconds ago   Up 3 seconds             nexus
cf611125e466   reg.ops:5000/strimzi/kafka-bridge:latest   "/opt/strimzi/bin/ka…"   8 hours ago     Up 8 hours               strimzi-bridge
dcf8e9f0bada   reg.ops:5000/traefik:xlatest               "/entrypoint.sh trae…"   8 hours ago     Up 8 hours               traefik
# 
# 

But as I said it broke. My rough analysis posted on gentoo forum was:

In the past ive had a more-or-less (s6 integration)[https://wiki.gentoo.org/wiki/S6] working with openrc/init and s6 starting/stopping containers.

Recently having issues since last update, may be related, but have found that starting services using supervisor=s6 in the init.d file no longer works.

Pre-existing scheme was I believe in line with above link:

Have my daemontools-like run services /var/svc.d/<MYSERVICE>/run,...

When [init.d] s6 starts service, a link was made

/var/svc.d/<MYSERVICE> /run/openrc/s6-scan/<MYSERVICE>

Everything worked.

Now getting everything is trying to run services via /run/openrc/s6-services/<MYSERVICE>. This folder ends up getting created and it no longer links to /var/svc.d/<MYSERVICE>, its a folder with an auto-generated dummy run file.

I've found I can hack around it by forcing the _serivicedirs variable /usr/libexec/rc/sh/s6.sh to /var/svc.d, instead of /run/openrc/s6-services. ie s6 then correctly sources the service(s) from /var/svc.d, not some ?cache-related, indirection related /run/openrc/s6-services folder. Its like some [sys-apps/openrc-0.63] s6.sh script is coded for services in /run/openrc/s6-services folder, and when it cant find them, goes down its own path of creating and linking services folders. However as per doc, service dirs are conventionally found in /var/svc.d/... and get picked up from there and linked into /run/openrc/s6-scan for s6-svscan pickup.

WORKAROUND

I have a workaround in place, which is to comment out/replace some lines in the /usr/libexec/rc/sh/s6.sh file:

...

# Call this on every entry point, for readability
_s6_set_variables() {
  name="${name:-${RC_SVCNAME}}"
  _execlineb="$(command -v execlineb)"
  _scandir="${RC_SVCDIR}/s6-scan"
  ##### _servicedirs="${RC_SVCDIR}/s6-services"  ######
  _servicedirs="/var/svc.d"
  _service="$_scandir/$name"
}
...

}

s6_start()
{
  local r waitcommand waitname
  _s6_set_variables
  if ! _s6_sanity_checks ; then
    eerror "s6 sanity checks failed, cannot start service"
    return 1
  fi
  ##### if _s6_servicedir_creation_needed ; then
  # ###  ebegin "Starting $name"
  ##### _s6_servicedir_create
  ##### else
  #####  ebegin "Starting $name (using cached service directory)"
  ##### fi
  if s6-svlink -- "$_scandir" "$_servicedirs/$name" ; then : ; else
    r=$?
    eend $r "Failed to s6-svlink $name into $_scandir"
    return $r
  fi
  if test -n "$timeout_ready" ; then
    if test -n "$notify" ; then
      waitcommand='-U'
      waitname=ready
    else
      waitcommand='-u'
      waitname=up
    fi
    if s6-svwait $waitcommand -t "$timeout_ready" -- "$_service" ; then : ; else
      r=$?
      s6-svc -d -- "$_service"
      eend $r "Failed to become $waitname in $timeout_ready milliseconds"
      return $r
    fi
  fi
  eend 0
}

s6_stop() {
  _s6_set_variabl
....

[navi-desu]

@skarnet reworked the s6 support in openrc to use the native openrc variables in 0.63

i have a flight to catch in a few hours but i'll look at this properly after landing, i don't think neither ska nor i thought of leaving compat for the old service dir path, sorry

[skarnet]

Yup, that was my bad: I changed how the s6 support worked in OpenRC, with zero regard for compatibility. Because the old way essentially brings you no benefit over using s6 separately from OpenRC: it's not an integration, it's just "oh by the way we can run an s6 supervision tree as well". And to be honest, I didn't think anyone was using it. I was wrong.

So yes, the new support basically creates the service directory for you from the init.d file, following the same format as any OpenRC service file; and service directories are cached, they're not meant to be the authoritative source of information. Because since it's OpenRC, the authoritative source of information is the OpenRC service file.

But I should have planned a way to keep the existing setups working, i.e. if you already have service directories that you just want to start a supervisor on, you should be able to do that. I will add this as soon as I can (I should be able to work on this next week). Sorry for the inconvenience, you will soon have a way to run your existing setup without changes.