Bug 1312384 - systemd-nspawn --setenv is too strict
systemd-nspawn --setenv is too strict
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2016-02-26 10:22 EST by Miroslav Suchý
Modified: 2016-08-08 13:44 EDT (History)
8 users (show)

See Also:
Fixed In Version: systemd-229-1.fc24
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-08-04 01:00:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Miroslav Suchý 2016-02-26 10:22:13 EST
Description of problem:
Mock using environment variable:
  config_opts['environment']['PROMPT_COMMAND'] = 'printf "\033]0;<mock-chroot>\007<mock-chroot>"'
See bug 1126235 for history if you want to know why.

And when I use systemd-nspawn in mock. (--new-chroot option) It will execute:
DEBUG: doshell: command: ['/usr/bin/systemd-nspawn', '-q', '-M', '1b48214dd52d4132aa711e3408619c74', '-D', '/var/lib/mock/epel-7-x86_64/root', '--setenv=FOO=BAR', '--setenv=HOSTNAME=mock', '--setenv=PROMPT_COMMAND=printf "\x1b]0;<mock-chroot>\x07<mock-chroot>"', '--setenv=SHELL=/bin/bash', '--setenv=PATH=/usr/bin:/usr/sbin', '--setenv=TERM=vt100', '--setenv=LANG=cs_CZ.UTF-8', '--setenv=HOME=/builddir', '/bin/sh', '-i', '-l']
Note that this is not even master. I discovered that during work on mock bug 1311796.

Which will fails with:
  Environment variable assignment 'PROMPT_COMMAND=printf "<mock-chroot>"' is not valid.

I suppose that it is because you check if the character is UTF.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. systemd-nspawn -q -M 1b48214dd52d4132aa711e3408619c74 -D /var/lib/mock/epel-7-x86_64/root '--setenv=PROMPT_COMMAND=printf "\x1b]0;<mock-chroot>\x07<mock-chroot>"'

Actual results:
variable is not valid

Expected results:
no errors because that variable is perfectly valid

Additional info:
Until this get resolved Mock will use simpler PROMPT for nspawn.
Comment 1 Jan Synacek 2016-02-29 09:09:50 EST
Works for me...

$ rpm -q systemd

$ sudo systemd-nspawn -bM rawhide --setenv='PROMPT_COMMAND=printf "\x1b]0;<mock-chroot>\x07<mock-chroot>"'

<Boots fine...>

In the container:
# cat /proc/1/environ 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bincontainer=systemd-nspawnTERM=xterm-256colorHOME=/rootUSER=rootLOGNAME=rootPROMPT_COMMAND=printf "\x1b]0;<mock-chroot>\x07<mock-chroot>"

# sudo env | grep PROMPT
# sudo systemctl show-environment | grep PROMPT

The --setenv only passes the environment to the init of the container. I'm not sure if it's currently possible to pass an environment variable to the entire container.

Maybe Zbyszek knows?
Comment 2 Zbigniew Jędrzejewski-Szmek 2016-03-21 16:53:09 EDT
I can't reproduce the problem using nspawn directly either.
https://github.com/systemd/systemd/pull/2880 adds some more tests.
Comment 3 Zbigniew Jędrzejewski-Szmek 2016-03-21 17:05:48 EDT
I tried setting  config_opts['environment']['PROMPT_COMMAND']  in mock config in various ways and it doesn't seem to have any effect when --new-chroot is specified.
Comment 4 Zbigniew Jędrzejewski-Szmek 2016-03-21 23:54:25 EDT
Maybe you need one more level of escaping?
Comment 5 Jan Kurik 2016-07-26 01:06:30 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.
Comment 6 Zbigniew Jędrzejewski-Szmek 2016-08-04 01:00:28 EDT
Passing of the environment variable seems to work fine.

The variable is set for the init process in the container. To pass it to child processes, PassEnvironment should be used: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PassEnvironment= (added in systemd-228).
Comment 7 Miroslav Suchý 2016-08-08 13:44:36 EDT
OK, I can confirm that with
it works. Even the reproducer from #0.

Note You need to log in before you can comment on or make changes to this bug.