erlware / relx

Sane, simple release creation for Erlang
http://erlware.github.io/relx
Apache License 2.0
697 stars 232 forks source link

Implement systemd-like support for hook directories #742

Closed saleyn closed 2 years ago

saleyn commented 5 years ago
  1. A new variation of the extended_start_script_hooks option is added that can define a source directory containing hook scripts: {directory, HookScriptsDir::string()}. When defined, the scripts will be copied to a sub-folder in the release at the level of the extended start script. That subfolder will have the same name as the basename of the extended start script (without the release version number and extension), and will have a .d suffix.

  2. That subdirectory can contain pre-/post- start/stop/install scripts with by saving them in the startup script's release directory that has a .d suffix. So, if the extended script's name is myapp.sh, then the hook directory can be:

    bin
    +-- myapp.sh   <-- Extended start script
    +-- myapp.d
    +-- pre-start.NN
    +-- post-start.NN
    +-- pre-stop.NN
    +-- post-stop.NN
    +-- pre-install.NN
    +-- post-install.NN

    The hook extension files can have any suffix (such as .NN shown above). The files in this directory will be sourced only if the corresponding PRE_* or POST_* variables (populated by respective pre_* and post_* hook configuration options) don't contain script names that override this behavior.

tsloughter commented 5 years ago

Is this just a ways to define the already supported pre/post hooks but instead of putting the pre/post definition in the relx config it is resolved from the name of the script?

tsloughter commented 5 years ago

Hehe, cat hit the keyboard when I was going to comment and hit the 'close and comment' buton.

saleyn commented 5 years ago

Yes, I believe this approach is more transparent as the config way is a two-step process - you need to create the hook files, and then add them to the config, whereas this approach just uses the hooks files that the maintainer creates in the filesystem. It's very similar to the systemd's convention for service configuration files, shells (/etc/profile.d), and other software.