Re: Handling environment in s6

["Laurent Bercot" <ska-supervision@skarnet.org>]

>Is there anything in s6 equivalent to below of systemd?
>
>/bin/systemctl set-environment SERVICEFILE=$SERVICEFILE

  There is not.
  The process supervisor itself (s6-supervise) and the service scanner
(s6-svscan) do not use the environment. Services can define their
own environment in their run script.

  There are several tools that help you define an environment in a run
script. The most idiomatic one is s6-envdir:
  https://skarnet.org/software/s6/s6-envdir.html

  If you have EnvironmentFiles that come from systemd, or overall
prefer to define your environment variables in a file, you may find
the envfile program useful - it's in the execline package:
  https://skarnet.org/software/execline/envfile.html

  Or you can simply write your run script in shell, and define your
environment variables via the shell syntax, or via sourcing a file,
as a lot of distributions do with /etc/default/*.conf or similar
mechanisms.

  Providing a command that changes the supervisor's environment at
run time is one of the many useless - and in this case, harmful -
features of systemd. It is harmful because it introduces changes
between what's written on disk (which is what will happen at boot time,
and what the user can see when studying files) and the current state
of the supervisor, so future service operations will violate the
principle of least surprise. It destroys the "if it's working now then
it will work after I reboot" property. And of course having the
supervisor rely on externally modifiable environment variables makes
it more vulnerable.

  If I'm judging from your recent batch of questions these last few
weeks, you are trying to convert a set of systemd services to a s6
installation. This is a very good idea (;)) and I commend you for
taking up this task.
  However, listing all the systemd features and asking 'how do I
accomplish this in s6?' is not the right way to go about this. The
systemd features have been designed with the systemd mindset, and
individually they make sense (or not) in the context and with the
architecture of systemd. Trying to exactly map the features one-to-one
would result in writing another systemd behemoth, as the author of
uselessd discovered to their dismay.

  The s6 mindset is very different from the systemd one, and there is
no direct mapping from one to the other. In order to convert a set of
services, you need to take a step back and look at the big picture:
what high-level functionality do I need? how am I expressing that
functionality with systemd? what is the way to express it with s6?
It requires a deeper rework than just a syntactic one, which is why it
is really difficult to write an automatic converter, and why it is also
generally difficult to answer questions like yours without going into
the details of what exactly you're trying to do.

--
  Laurent