Waiting for daemon in configure hook and debugging

Hey,
I recently published the FidusWriter snap to the store. It works fine for me locally, but installing it on a VPN, I found two issues:

A) The configure hook needs the included mysql server in place for it to work. I used the same trick that the nextcloud snap uses: Let the hook wait for a file to be present that is being created by the mysql part:

from time import sleep

...
timer = 0
# We wait for the password file to be created
while timer < 10 and not os.path.isfile(PASSWORD_PATH):
    timer += 1
    sleep(1)
...

This should only add a wait time of maximum 10 seconds, but somehow it seems to take much longer than that. Is there any way I can debug the installation process and get more verbose output? Also, it seems to not work the first time I attempt to install the snap - and I cannot tell why. The installation doesn’t succeed, and this part works the second time. Is there a way to reset it to behave the same it did the first time?

B) The second installation attempt seems to be working, but configure hook is killed after 5 minutes when it is still not done and so the installation is halted. Is there a way for me to increase that limit? And if not, is there a way to move some things I do during the configure hook that are needed to have the system up and running to another hook?

What seems to work is to move the build of certain cache files from the config hook to the start of the daemon. But I then somehow need to communicate to the user that they need to wait 5-10 minutes after installing the package until it’s really up and running. Is there any way to do that?

Have you tried putting the code that waits for a file to a daemon, and order that daemon to run before the main daemon? then you can make the file-waiting daemon a oneshot daemon, and I think that the snap install will block waiting for that first daemon to finish before starting the second one (and then after the second daemon is started the snap install finishes). Typically hooks should be written to be as quick as possible, letting long running tasks be run elsewhere.

Hey @ijohnson do you know of any examples of creating such a first simple daemon that does something and then causes a second daemon to start and then exists? I couldn’t find anything on that here https://snapcraft.io/docs/services-and-daemons . The main simple daemon that I’m running right now seems to not influence when the installation process is finished.

Well it’s a quite complicated example, but there’s the edgexfoundry snap: https://github.com/edgexfoundry/edgex-go/blob/master/snap/snapcraft.yaml#L68-L340

To be clear, all I think you would need to do is something like this:

apps:
  wait-for-file:
    command: wait-for-file.sh
    daemon: oneshot
  do-thing-with-file:
    command: do-thing-with-file.sh
    daemon: simple
    after: 
      - wait-for-file

(also I originally had a typo and said that the wait-for-file daemon should be a simple daemon, this was wrong I meant oneshot daemon)