Hi! On Thu, 2023-07-06 at 18:41:38 +1000, Trent W. Buck wrote: > "Trent W. Buck" <trentb...@gmail.com> writes: > > e.g. I expect "SystemCallArchitectures=native" to break for a lot of > > people (anyone doing dpkg --add-architecture)
Yes, see #982456. > Short version: > > • SystemCallArchitectures=native + debianutils:i386 doesn't break > dpkg-db-backup.service. > • Probably savelog simply never calls an ARCHITECTURE-SPECIFIC syscall. That's because the only thing used from debianutils:i386 is savelog which is a shell script, and as long as you have dash:amd64 then that would work. The same would apply to any other interpreted program, as long as the interpreter matches the systemd native architecture. > • SystemCallArchitectures=native + nginx:i386 DOES break nginx.service. > • Neither journalctl nor coredumpctl makes it obvious this is WHY nginx > crashed. Right. > So I guess a program like savelog doesn't trigger it, because > it's so simple it never hits an architecture-specific syscall? Any binary program, will always at least call 1 syscall (either the implicit exit() from the libc CRT function calling main(), or an explicit exit() or raise() or similar to be able to terminate itself. So there's no escape from this. So SystemCallArchitectures=* seems fine as a local admin tool when they control their deployment or for very controlled distribution builders. Otherwise for a general purpose distribution where you can install foreign packages, it has always seemed like a bad idea to include them as part of the .deb, because it's depending on external implementation details, and this is not helped with the error failure mode. As I mentioned now on that report above, this could be made safe and be enabled for I guess all installed services (for free!) by "something" generating overrides based on the current list of dpkg architectures (could perhaps be added as a hook on dpkg for the add and remove architecture actions, or maybe as a generator, dunno). Thanks, Guillem
