Start a Service After a Resource is Mounted

Table of Contents

Introduction

If you have network resources, such as NFS or iSCSI-based mounts, and you want to make sure that another service only starts after the resource is mounted, then consider the following example setup when configuring your system.

The example below is based on an NFS mount which you want to be available before the service with <name.service> starts. The same procedure can be used for iSCSI. For details setting up an iSCSI mount see the Ubuntu iSCSI Initiator guide.

Example Setup

In general, the name in <name.service> could be any valid service like docker or others.

  • Add _netdev to the list of NFS mount point options in /etc/fstab.

    This option ensures that the mount happens after the network is up:

    resource:foreign_path local_path nfs (<your options>),_netdev

  • Make sure that all mounts in /etc/fstab are mounted by running:

    sudo mount -a

  • Run the following command to list mounts which must be up first:

    systemctl list-units | grep -nP "\.mount"

    You should see lines printed to the console. Look for the mount you want to be up.

    <folder.mount>
  loaded active mounted <local_path>

    where <folder.mount> and <local_path> are examples.

  • Edit the service you want to change:

    sudo systemctl edit <name>.service

    An editor opens. Add the following directive, using your chosen folder.mount from above:

    [Unit]
After=folder.mount

    If needed, you can add more than one dependency by separating them with spaces. This procedure keeps <name>.service in its original state but makes it possible to override the current setup with new parameters. This is necessary because during updates the original service data will be overwritten. It automatically creates a directory in /etc/systemd/system named <name>.service.d and a file in that directory called override.conf. In the example above, the parameter is added to the existing list of parameters of the After directive.

    For more details read section Example 2. Overriding vendor settings.

    Keep the following points in mind with regard to whether <name>.service is linked or not:

    • If the file is linked from /lib/systemd/system, it is for packaged unit files. They are overwritten when Systemd (or whatever package provides them) is upgraded.

    • If the file originates in /etc/systemd/system, it is for your own, possibly customized unit files. Unit files you place in here override the package-provided files and will not be replaced during an upgrade.

    It is recommended to keep things simple and future-proof by creating an override file via systemctl edit.

  • Run the following command to apply your changes:

    sudo systemctl daemon-reload

  • Check if <name>.service has been properly added:

    sudo systemctl show <name>.service | grep "After="

    folder.mount should be part of the parameter list.

  • Restart your service by invoking:

    sudo systemctl restart <name>