Install/remove hooks

2_30
pstolowski
#1

Hello,

I would like to know if pre service startup hooks are going to be implemented anytime soon?

I am maintaining simple version of this feature and would be happy to see some form of it in upstream.

Thank you

#2

Does this bug cover your use-case? I agree, I’ve been wanting something like this as well.

#3

Yes, this is exactly what I want, probably I should advertise my branch there :slight_smile:

#4

@niemeyer any thoughts on this?

#5

Yes, we should implement something like that. Some of the use cases go against the direction we want to run with snaps which is to make them more and more confined and isolated, but the lack of these scripts hasn’t really solved this problem and only made matters worse since people are fiddling with system settings and not restoring them. So we shouldn’t be fighting such real world use, and instead solve the immediate issue and then make classic snaps irrelevant over time.

#6

I’m a little confused by mixing service-startup hook concept with install/remove hooks. It’s seems we’re interested in install/remove hooks after all, as described in the bug 1661126 linked by @kyrofa.

If this is correct and we’re looking for install/remove hooks, then these hooks would be similiar to configure hook, with exceptions of course. My proposal:

  1. install hook gets executed when snap is installed, refreshed or reverted. It’s run before configure hook.
  2. If it’s desirable to distinguish between install and revert/refresh (upgrade), then refresh and revert may have separate hooks (or we may pass extra environment variables to indicate this fact to install).
  3. uninstall hook is only executed when last revision of snap is removed from the system.
  4. Both install and uninstall would be run in transactions when it comes to configuration changes made via snapctl (similiar to configure).
  5. Failure in install hook would abort the install, undo the tasks internally etc. However, I’m not sure if we should have an undo-install hook for failure on install during refresh. Perhaps if this was a refresh/revert, we should just run install hook of the previous revision?
  6. Failure in uninstall hook would log a warning, but would not abort snap removal.

I think that implementation of the suggestion regarding running install/uninstall hooks per-user (suggested in the comments of aforementioned bug report) is out of scope for now as this is a bigger shift in snapd.

#7

Not only before the configure hook, but before services are fired up, right?

#8

Oh yes, sure, it would run before start-snap-services task internally. Thanks for pointing out.

#9

PR for install / remove hooks: https://github.com/snapcore/snapd/pull/3498

Refresh/revert hooks PR will follow soon.

#10

Refresh:

UPDATE: after some face-2-face discussion we decided not provide revert hooks at this moment as those are more tricky and we need to understand real use-cases better before introducing them.

The snapd roadmap
Released: snapd 2.28
#11

This PR looks very good and looks really helpful for generating configs on install (https://github.com/snapcore/snapd/blob/master/overlord/snapstate/snapstate.go#L173), but what what about upgrades? How can I bring updated config templates for regeneration with new version of my app?

#12

This should be handled by the refresh hook proposed by @pstolowski above. Still in the queue, but should go in soon.

#13

The support for refresh hooks has undergone some internal changes before making it into 2.30 release. At the end of the refining process we have two new hooks (both optional of course) executed when snaps are refreshed:

  • pre-refresh - executed against the old revision of the snap, before its services are stopped, giving it a chance to do any maintenance or preparations needed for the update.
  • post-refresh - executed against the new revision of the snap, before its services are started.