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).
We just discussed the issue with the hardcoded stop timeout with the following conclusion:
- We increase the hardcoded start/stop/restart timeout for services from 5s to 60s as a short term measure.
- We rework the
overlord/servicestate
code to reuse the systemd related code from thesystemd
andwrappers
packages to avoid duplication of code in this area. This probably means that we servicestate code from using genericcmdstate.Exec()
tasks that just exec systemctl commands to “real” tasks like “start-service”, “stop-service”, “restart-service” and inside the handlers using thesystemd
andwrappers
packages code.
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 onlystop --disable
would turn off sockets/timers as well
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.