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" <>
To: "billa chaitanya" <>,
Subject: Re: Handling environment in s6
Date: Tue, 10 Nov 2020 11:17:58 +0000
Message-ID: <em8b5321e4-871d-4600-b61f-dd0dcbfe0451@elzian> (raw)
In-Reply-To: <>

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

  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:

  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

  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.


      reply	other threads:[~2020-11-10 11:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-10 10:11 billa chaitanya
2020-11-10 11:17 ` Laurent Bercot [this message]

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 \
    --in-reply-to=em8b5321e4-871d-4600-b61f-dd0dcbfe0451@elzian \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit

This inbox may be cloned and mirrored by anyone:

	git clone --mirror

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 supervision supervision/ \
	public-inbox-index supervision

Example config snippet for mirrors.
Newsgroup available over NNTP:

AGPL code for this site: git clone