As you can see with session below, schroot throws away the processor
affinities present in the parent process.  This breaks a common
strategy (used e.g. by slurm) for sharing multi-processor machines.

╭─ simplex:~
╰─% grep Cpus_allowed_list /proc/self/status
Cpus_allowed_list:      0,2,4,6,8,10,12,14,16,18,40,42,44,46,48,50,52,54,56,58
╭─ simplex:~
╰─% schroot -c sid grep Cpus_allowed_list /proc/self/status
Cpus_allowed_list:      0-79


- -- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages schroot depends on:
ii  libboost-filesystem1.74.0       1.74.0-8
ii  libboost-iostreams1.74.0        1.74.0-8
ii  libboost-program-options1.74.0  1.74.0-8
ii  libc6                           2.31-9
ii  libgcc-s1                       10.2.1-6
ii  libpam0g                        1.4.0-2
ii  libstdc++6                      10.2.1-6
ii  libuuid1                        2.36.1-6
ii  lsb-base                        11.1.0
ii  schroot-common                  1.6.10-11

schroot recommends no packages.

Versions of packages schroot suggests:
pn  aufs-tools | unionfs-fuse  <none>
ii  btrfs-progs                5.10-1
ii  debootstrap                1.0.123
ii  lvm2                       2.03.11-2
ii  qemu-user-static           1:5.2+dfsg-3
pn  zfsutils-linux             <none>

- -- Configuration Files:
/etc/schroot/sbuild/fstab changed [not included]

- -- no debconf information
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmARz30ACgkQA0U5G1Wq
FSEh5A/9GLOpmcFnAOm8xIJvcbHyq4AVewbOWIrrZ4UcKCLL/CA3eGbgWcmfhA0l
qJD64wLE9DRBxARSfR0eJjSquWeBd1BhsiYPvhpJ20E5gNzecFFdNbl7zl7YiiMv
lGyI5w2CfO4WR+qqOthf5trtonSuiFf1SazCbSWoGnv2CZd6QUCtY8NSSUcHOhBd
Xq+dgtRLIoXBcThIXqcTVbeUUahBfip4/SRH9XF9Y2zeVACmISXIX/G9wWxCMnjV
ltTFTCI9he4KxBXvkz7JS/lw/FmZW77XkIqdJYVuRG/UOHtTtJrWgmP/CTNaUD0X
fH/eP3RT94oFXWq1CJsH7mZAczZKDR4NGowhiYlKVh4SxJ/WhAD5rgbquCCc7ROx
TQg7k9raP74YMQ1zwCfNih8SOwDPhZq00pxRo0VFk40nv+2hahqH+pqgpRlMGsXb
3Lyx/2cS44Q52nJZcNJvnRg64xCRauQAQHK+Z5dFsJfFlv/V6avdh0iEB/ypXFVC
KJvMQHm7UXJuWN7DqzGCPKvDnWKlWKX3dlHugE7MM2kCNxUqFP6/eGU6ABSc/oei
BecLbmp/zw9RYbVgpsmIjJ/qyIXsMlE9t1z7+bNoq/ImuQQsI3zNduFrn3eKbdBv
NOqFTkDGN+fF7S0UzIhFF1M2R+V/voXlJlKk4BsoTpgo3IGcGW4=
=E1e3
-----END PGP SIGNATURE-----

We don’t actively do anything within schroot to change this, so it must be a side-effect of some action it takes during session setup.

The main actions under our control are basic fork/chroot/setuid/setgid/exec and I doubt these are responsible.

The PAM auth and session handling is I think the most likely culprit, and this is not under our direct control.  Is there a particular PAM module which can change these cpusets?  If so, can you edit the schroot PAM configuration and see if it can be disabled this way?  Possibly in @common-session?


Thanks,
Roger

Roger Leigh <rleigh@codelibre.net> writes:

I'm not sure (yet) what if any  pam module resets the Cpu_allowed mask,
but your idea seems worth investigating to me, since I noticed the same
behaviour with su.

d