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
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
Does this bug cover your use-case? I agree, I’ve been wanting something like this as well.
Yes, this is exactly what I want, probably I should advertise my branch there
@niemeyer any thoughts on this?
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.
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:
install
hook gets executed when snap is installed, refreshed or reverted. It’s run before configure
hook.uninstall
hook is only executed when last revision of snap is removed from the system.install
and uninstall
would be run in transactions when it comes to configuration changes made via snapctl (similiar to configure
).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?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.
Not only before the configure
hook, but before services are fired up, right?
Oh yes, sure, it would run before start-snap-services task internally. Thanks for pointing out.
PR for install / remove hooks: https://github.com/snapcore/snapd/pull/3498
Refresh/revert hooks PR will follow soon.
Refresh:
https://github.com/snapcore/snapd/pull/3526
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.
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?
This should be handled by the refresh hook proposed by @pstolowski above. Still in the queue, but should go in soon.
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: