The `snap stop` command hardcodes a 5s timeout

snapd
1

This was reported recently. When doing snap stop <service> the stop-timeout of the service is not honoured but a 5s timeout is always hardcoded. It looks like this is because of the way that servicestate.go is implemented (it does not use wrappers/service.go).

2

We just discussed the issue with the hardcoded stop timeout with the following conclusion:

  1. We increase the hardcoded start/stop/restart timeout for services from 5s to 60s as a short term measure.
  2. We rework the overlord/servicestate code to reuse the systemd related code from the systemd and wrappers packages to avoid duplication of code in this area. This probably means that we servicestate code from using generic cmdstate.Exec() tasks that just exec systemctl commands to “real” tasks like “start-service”, “stop-service”, “restart-service” and inside the handlers using the systemd and wrappers packages code.
3

we also discussed what should stop and friends do in the face now of services with sockets, or timers. The initial strawman is that:

  • stop alone would affect the service only
  • stop --disable would turn off sockets/timers as well
4

I am following up wrt Snap stop command timeouts , It would be great if snap stop command can honor TimeoutStopUSec as set with stop-timeout . Any thing that is hardcoded may fail for one or the other services.

Thanks.