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.
interfaces/network-manager: move deny ptrace to the connected slot (#6975)
The deny ptrace was not really activated as it was in the permanent slot
while it was using the PLUG_SECURITY_TAGS expression, which only exists
in the connected slot. Move deny ptrace there. Fixes LP: #1797194.
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.
Introduce GetType() function for snap.Info and rename Info.Type to SnapType to catch all cases where Type is read (or compared). This is preparation for "snapd" type handling.
