This is still present in jammy as
debian/patches/debian/UBUNTU-Revert-namespace-be-more-careful-when-handling-namespacin.patch
If we want to keep this as long as there could be an 18.04 that is like 2028 at
least.
So AFAIU this bug is actually asking LXD to consider a backport (if
possible) to then drop the revert from systemd (all releases).
** Also affects: lxd (Ubuntu)
Importance: Undecided
Status: New
** Also affects: systemd (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: lxd (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: systemd (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: lxd (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: systemd (Ubuntu Impish)
Importance: Undecided
Status: New
** Also affects: lxd (Ubuntu Impish)
Importance: Undecided
Status: New
** No longer affects: lxd (Ubuntu Focal)
** No longer affects: lxd (Ubuntu Impish)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1959047
Title:
systemd ignores RootDirectory option in .service units
Status in lxd package in Ubuntu:
New
Status in systemd package in Ubuntu:
Confirmed
Status in lxd source package in Bionic:
New
Status in systemd source package in Bionic:
New
Status in systemd source package in Focal:
New
Status in systemd source package in Impish:
New
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1959047/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
