Mount point availability and hook script post-start phase

[Waterfin]

What is the order of execution for when an LXC container is started when it has both a mount point (bind mount in this case) and a hook script set?

Example lxc config:

hostname: ct1
ostype: debian
arch: amd64
cores: 1
memory: 1024
swap: 1024
rootfs: local:100/vm-100-disk-0.raw,size=10G
onboot: 0
unprivileged: 1
mp0: /mnt/bindmounts/shared,mp=/root/post-start.d,ro=1
hookscript: local:snippets/hook.sh

I am trying to execute a command from the container hook script (hook.sh) at the "post-start" phase which depends on files contained within the bind mount point (mp0). This fails because at the time the hook script post-start phase is executed, the local mount point directory (/root/post-start.d in this example) does not exist.
I assume that the "post-start" phase does not wait for mount points to finish mounting before executing, is this true? At what point exactly does the "post-start" phase happen?

 

[Stefan_R]

The hook script does not run inside the container, but on the PVE host. Thus the bindmount will not be visible, as it will only be mounted within the CTs mount namespace. If you need to change something in that directory, you'd have to access it via /mnt/bindmounts/shared in this example.

 

[Waterfin]

I did not realize that hook scripts were run on the PVE host as it wasn't mentioned anywhere in the documentation that I saw.
If I wanted to execute a command within a container from a hook script, then I would also have to use pct exec in the hook script since the hook script itself is running on the PVE host, correct?

 

[Stefan_R]

Yes, although pct exec from a container hook script might be a bad idea.

Since you hook into 'post-start' though, what stops you from just registering a startup task within the container, i.e. a systemd service or "@reboot" cronjob?

 

[Waterfin]

I want simple and maintainable deployment of containers. Some containers will need different system packages installed after first boot, for example. Not all containers will have the same deployment environment though.
I realize now that hook scripts are probably not the way to go for this.