Categories

## EnvironmentFiles used by systemd

In a previous posting, Environment variables set by systemd, variables were directly set within the systemd unit file. This is fine for a small amount of modifications, but in some case these environment variables are provided by another package on the system or need to be the same for multiple services.

We have modified our Python application to print all environment variables that are set to make this example easier.

#!/usr/bin/env python3

import os

for param in os.environ.keys():
print("%20s %s" % (param, os.environ[param]))


We create the first environment file /usr/local/env/file1 with the content as below to assign string values to variables. Just as in the systemd unit file no string interpolation is being done, only lines with an equal sign are processed and everything after a hash sign is ignored.

FVAR1="test1"
FVAR2="test2"


We also create a second environment file /usr/local/env/file2 with the content below. Directly we see that variable FVAR1 is also be declared in this environment file.

FVAR1="TEST1"
FVAR3="Test3"


To use the environment files we need to declare them in the systemd unit file below. The line for file1 shows that we require the file to be present otherwise the service will fail, but for file2 the filename has been preceded by a hyphen to indicate to systemd that the file is optional and no error will be generated if it is absent.

[Unit]
Description=App Service

[Service]
Type=simple
EnvironmentFile=/usr/local/env/file1
EnvironmentFile=-/usr/local/env/file2
Environment="VAR0=hello world"
ExecStart=/usr/local/bin/app


After restarting the application with systemd all the environment variables that were set are shown in the system journal. The most interesting variable shown is FVAR1 as we declared it in two files earlier and we see that the value set in file1 was replaced by the value set in file2 that was processed later.

$sudo systemctl daemon-reload$ sudo systemctl restart app.service
default
$VAR1=test ./main.py test  Setting the environment variables via systemd is done by adding the attribute Environment to the Service section of the unit file for the service. After a systemctl daemon-load the environment variable will be set when you start or restart the service. ... [Service] Environment="VAR1=hello" ...  If more variables need to be set, then more Environment attributes can be added to the Service section. ... [Service] Environment="VAR1=hello" Environment="VAR2=world" ...  While it may break some human workflows in the beginning, but in long term it is a good step for following the infrastructure as code path as Ansible could be used for managing these variables. Also storing these kind of variables in the same way makes both troubleshooting and collecting settings for an audit easier. Categories ## PAM bug hit Debian and others It has been years since PAM was hit by a serious bug in PAM, but people who upgrade to libpam-systemd version 44-1 can find that sudo stops working. Reading the bugreport on Debian and FreeDesktop.org it doesn’t look promising as it also effects other distributions. For now it may be wise put systemd on hold in case the package transfers from unstable to testing. Categories ## A smoother transition in Debian About a month ago a transition in Debian took a wrong turn for systemd users. This ended in systemd users who where unable to shutdown there system, but recently a newer version was uploaded to unstable solving this issue. So time to unlock the block packages and upgrading systemd to version 37-1.1 and blocked packages. echo "bootlogd install" | sudo dpkg --set-selections echo "initscripts install" | sudo dpkg --set-selections echo "sysvinit install" | sudo dpkg --set-selections echo "sysvinit-utils install" | sudo dpkg --set-selections echo "sysv-rc install" | sudo dpkg --set-selections sudo apt-get install -t unstable systemd libpam-systemd libsystemd-daemon0 libsystemd-login0 bootlogd initscripts sysv-rc sysvinit sysvinit-utils  Only remark after upgrade as for the last time a normal reboot isn’t possible since the system already looks at the new location, but a halt -f solves that. Categories ## No smooth transition in Debian Bugreport 638019 appears to be very straight forward, until the code finally hit Debian Testing last weekend. A simple relocation of a FIFO-buffer from /dev to /run caused direct trouble for machines with systemd and a normal shutdown wasn’t possible anymore. Both bugs 657979 and 657990 are a results of the modification. Seeing the overview of effected files and made me go back to the previous working release of source package sysvinit with the following commands $ cd xdg-user-dir DOWNLOAD
$wget http://snapshot.debian.org/archive/debian/20111223T034013Z/pool/main/s/sysvinit/bootlogd_2.88dsf-18_amd64.deb$ wget http://snapshot.debian.org/archive/debian/20111223T034013Z/pool/main/s/sysvinit/initscripts_2.88dsf-18_amd64.deb
$wget http://snapshot.debian.org/archive/debian/20111223T034013Z/pool/main/s/sysvinit/sysv-rc_2.88dsf-18_all.deb$ wget http://snapshot.debian.org/archive/debian/20111223T034013Z/pool/main/s/sysvinit/sysvinit-utils_2.88dsf-18_amd64.deb
$wget http://snapshot.debian.org/archive/debian/20111223T034013Z/pool/main/s/sysvinit/sysvinit_2.88dsf-18_amd64.deb$ dpkg -i bootlogd_2.88dsf-18_amd64.deb initscripts_2.88dsf-18_amd64.deb sysvinit_2.88dsf-18_amd64.deb sysvinit-utils_2.88dsf-18_amd64.deb sysv-rc_2.88dsf-18_all.deb


And as there is no solution for now except a dependency change for systemd the package are being placed on hold like the last time they broke systemd.

echo "bootlogd hold" | sudo dpkg --set-selections echo "initscripts hold" | sudo dpkg --set-selections
echo "sysvinit hold" | sudo dpkg --set-selections echo "sysvinit-utils hold" | sudo dpkg --set-selections
\$ echo "sysv-rc hold" | sudo dpkg --set-selections


It sounds strange for Linux-people, but I really wished I had an alternative boot environment like Solaris has. Maybe this is the reason for me to invest more time in read-write within BtrFS.