#!/bin/sh -e

. /usr/lib/s6-policy-common/lib/svctl-common.sh

policy=$(readlink /usr/lib/s6-rc/policy/current)
if test x"$policy" = x"exclusive" ; then
  top="top"
elif test x"$policy" = x"shared" ; then
  top="runlevel_2"
else
  echo "svctl-apply: fatal: /usr/lib/s6-rc/policy/current should be a relative symlink to either shared or exclusive" 1>&2
  exit 100
fi

/usr/lib/s6-policy-common/bin/svctl-update

# MIT Zeitlimit -- ohne eines wartet s6-rc unbegrenzt, und das ist hier der
# teuerste Pfad von allen: "invoke-rc.d <dienst> start" landet auf genau diesem
# apply, und Fremd-postinsts rufen es bei jeder Installation. Gemessen am
# 24.09.2026 an zabbix-proxy: "s6-rc -p change top" lief 150 Sekunden und weiter,
# waehrend dpkg seine Sperre hielt -- obwohl 1.1.2 das Limit fuer dpkg-Laeufe auf
# 20 s gesenkt hatte. Der Grund war diese Zeile: 1.0.7 hat das Limit in
# svctl-update/start/stop/restart eingebaut und apply vergessen. Die Zahl war
# also richtig und wirkungslos.
timeout="$(svctl_timeout)"
rc=0
s6-rc -p -t "$timeout" change "$top" || rc=$?
if [ "$rc" != 0 ]; then
  echo "svctl-apply: fatal: der Zustandswechsel auf '$top' ist fehlgeschlagen oder hat das Limit von" 1>&2
  echo "svctl-apply:        ${timeout} ms gerissen (s6-rc rc=${rc})." 1>&2
  # Keine Detail-Diagnose hier: welche Dienste haengen, sagt "svctl liststate"
  # ehrlicher als eine Liste, die ich aus dem Zustand VOR dem Wechsel raten
  # muesste. Wenn die Sperre gehalten wird, ist auch das eine Auskunft.
  if ! svctl_load_active; then
    svctl_report_unmeasurable
  else
    echo "svctl-apply:        Welche Dienste nicht im gewollten Zustand sind, zeigt 'svctl liststate'." 1>&2
  fi
  exit "$rc"
fi
