Comment 0 for bug 1959047

The version of systemd (249.5-2ubuntu4) currently packaged for the Ubuntu development version (22.04 Jammy Jellyfish) totally ignores the RootDirectory= option in systemd service files. With RootDirectory, systemd should start the service after calling chroot() on the supplied directory.

To test/reproduce, create a test service file with the following contents:

# /etc/systemd/system/lsb-release.service
[Unit]
Description=LSB Release Information

[Service]
Type=simple
RootDirectory=/var/chroot/trusty
ExecStartPre=/bin/pwd
ExecStart=/usr/bin/lsb_release -a

You should have a chroot environment in the specified RootDirectory, even though you can still deduce if systemd attempted to chroot or not from the resulting error message.

In my example, I installed an end-of-life Ubuntu 14.04 Trusty Tahr in the chroot environment. On systems NOT affected by the problem, I get the following result when I start this test service. This is what I'd expect.

Jan 25 20:40:40 dolly systemd[1]: Starting LSB Release Information...
Jan 25 20:40:40 dolly pwd[361]: /
Jan 25 20:40:40 dolly systemd[1]: Started LSB Release Information.
Jan 25 20:40:40 dolly lsb_release[362]: No LSB modules are available.
Jan 25 20:40:40 dolly lsb_release[362]: Distributor ID: Ubuntu
Jan 25 20:40:40 dolly lsb_release[362]: Description: Ubuntu 14.04 LTS
Jan 25 20:40:40 dolly lsb_release[362]: Release: 14.04
Jan 25 20:40:40 dolly lsb_release[362]: Codename: trusty
Jan 25 20:40:40 dolly systemd[1]: lsb-release.service: Succeeded.

On the problematic system, however, I get the following result.

Jan 25 21:21:08 savelog systemd[1]: Starting LSB Release Information...
Jan 25 21:21:08 savelog systemd[1]: Started LSB Release Information.
Jan 25 21:21:08 savelog pwd[81114]: /
Jan 25 21:21:08 savelog lsb_release[81115]: No LSB modules are available.
Jan 25 21:21:08 savelog lsb_release[81115]: Distributor ID: Ubuntu
Jan 25 21:21:08 savelog lsb_release[81115]: Description: Ubuntu Jammy Jellyfish (development branch)
Jan 25 21:21:08 savelog lsb_release[81115]: Release: 22.04
Jan 25 21:21:08 savelog lsb_release[81115]: Codename: jammy
Jan 25 21:21:08 savelog systemd[1]: lsb-release.service: Deactivated successfully.

It totally run the service on the host's root filesystem, it didn't care even the slightest that a RootDirectory is specified.

Tested on the following releases / systemd versions:

Ubuntu 18.04.6 Bionic Beaver – ISSUE NOT PRESENT
systemd 237
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid

Ubuntu 20.04.3 Focal Fossa – ISSUE NOT PRESENT
systemd 245 (245.4-4ubuntu3.15)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid

Ubuntu 21.10 Impish Indri – ISSUE NOT PRESENT
systemd 248 (248.3-1ubuntu8.2)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

Ubuntu 22.04 Jammy Jellyfish (development branch) – ISSUE PRESENT
systemd 249 (249.5-2ubuntu4)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

Note that the problem is produced under an LXC container; since systemd detects virtualization, it might change how it behaves.

It's either a bug or an intentional change I don't understand yet (i.e. the RootDirectory option has deprecated and is about to be replaced with something else, or there are additional conditions to be met before RootDirectory is considered), but I think in the latter case I should at least get a warning that there is a change in configuration. I imagine suddenly everyone's existing service units utilizing RootDirectory silently stop working without any information regarding why.