The snap-seccomp helper maintains a list of all know syscalls supported by
libseccomp. We catch when the internal list diverges from upstream libseccomp in
a tests/main/snap-seccomp-syscalls spread test.
Upstream libseccomp has been updated with io_uring syscalls, update the internal
list.
Signed-off-by: Maciej Borzecki <email address hidden>
daemon: increase `shutdownTimeout` to 25s to deal with slow HW
We got a bugreport from a customer that they get core refresh
errors. We see the following error in the journal:
```
cannot gracefully finish, still active connections...
```
This indicates that the HW is just too slow to deal with this
in the 5s timeout. This means that snapd does not exit cleanly
and systemd will restart it. This will mean that snapd gets
to WaitRestart() again and assumes a system restart has happend
(but only snapd was restarted). This leads to an abort of the
install as it looks (for snapd) like there was a rollback during
the reboot because the core revision has not changed.
There are multiple issues here that needs addressing. The first
one is that the timeout needs to be bigger and that it should
not be an error but a warning. The error in this situation will
not stop the shutdown so the still-connected client do not
benefit and the side-effect of the unclean exit is undesired.
So this PR increases the timeout and turns the error into a
warning.