Comment 1 for bug 1962286

I looked a bit more into the trusty failure and it seems like that isn't a cgroups issue, since it doesn't use systemd and instead uses upstart, which doesn't seem to care about what cgroup is mounted. On trusty, the problem appears to be that it's simply too old to run with the python from jammy.

By default, trusty sshuttle attempts to use 'python' on the remote system, which no longer exists in jammy.

If --python is manually specified using jammy's python3, it fails:

root@test-t:~# sshuttle --python python3 -r ubuntu@10.46.117.1 1.1.1.1/24
ubuntu@10.46.117.1's password:
  File "<string>", line 1
    import sys; skip_imports=1; verbosity=0; exec compile(sys.stdin.read(764), "assembler.py", "exec")
                                                  ^
SyntaxError: invalid syntax
client: fatal: server died with error code 1

If --python is manually specified using jammy's python2 (which isn't installed by default), that still fails:

root@test-t:~# sshuttle --python python2 -r ubuntu@10.46.117.1 1.1.1.1/24
ubuntu@10.46.117.1's password:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "assembler.py", line 26, in <module>
  File "server.py", line 170, in main
  File "server.py", line 71, in list_routes
  File "server.py", line 51, in _list_routes
  File "ssubprocess.py", line 606, in __init__
  File "ssubprocess.py", line 1117, in _execute_child
OSError: [Errno 2] No such file or directory
client: fatal: server died with error code 1

So it may not be possible to use sshuttle from trusty->jammy at all, unfortunately, and the jammy autopkgtests might need to just stop running the trusty->jammy tests completely.

Note that the jammy->trusty connection does appear to work.