Set systemd service to execute after fstab mount












18














I'm working on a systemd .service script that is supposed to start after a CIFS network location is mounted via /etc/fstab to /mnt/ on boot-up.



The script waits for an OpenVPN dependency script to launch first, but I also want it to wait for mount to complete.



/etc/systemd/system/my-daemon.service:



[Unit]
Description=Launch My Daemon
After=network.target vpn-launch.service
Requires=vpn-launch.service


I tried to add systemd.mount to the line: After=network.target vpn-launch.service systemd.mount, but it didn't give the results I was hoping for.










share|improve this question
























  • Does it work if you add systemd-remount-fs to your After list?
    – Eric Renouf
    Dec 4 '15 at 19:13
















18














I'm working on a systemd .service script that is supposed to start after a CIFS network location is mounted via /etc/fstab to /mnt/ on boot-up.



The script waits for an OpenVPN dependency script to launch first, but I also want it to wait for mount to complete.



/etc/systemd/system/my-daemon.service:



[Unit]
Description=Launch My Daemon
After=network.target vpn-launch.service
Requires=vpn-launch.service


I tried to add systemd.mount to the line: After=network.target vpn-launch.service systemd.mount, but it didn't give the results I was hoping for.










share|improve this question
























  • Does it work if you add systemd-remount-fs to your After list?
    – Eric Renouf
    Dec 4 '15 at 19:13














18












18








18


4





I'm working on a systemd .service script that is supposed to start after a CIFS network location is mounted via /etc/fstab to /mnt/ on boot-up.



The script waits for an OpenVPN dependency script to launch first, but I also want it to wait for mount to complete.



/etc/systemd/system/my-daemon.service:



[Unit]
Description=Launch My Daemon
After=network.target vpn-launch.service
Requires=vpn-launch.service


I tried to add systemd.mount to the line: After=network.target vpn-launch.service systemd.mount, but it didn't give the results I was hoping for.










share|improve this question















I'm working on a systemd .service script that is supposed to start after a CIFS network location is mounted via /etc/fstab to /mnt/ on boot-up.



The script waits for an OpenVPN dependency script to launch first, but I also want it to wait for mount to complete.



/etc/systemd/system/my-daemon.service:



[Unit]
Description=Launch My Daemon
After=network.target vpn-launch.service
Requires=vpn-launch.service


I tried to add systemd.mount to the line: After=network.target vpn-launch.service systemd.mount, but it didn't give the results I was hoping for.







debian systemd






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 16 at 3:54









Rui F Ribeiro

38.9k1479129




38.9k1479129










asked Dec 2 '15 at 17:45









Winterflags

2392621




2392621












  • Does it work if you add systemd-remount-fs to your After list?
    – Eric Renouf
    Dec 4 '15 at 19:13


















  • Does it work if you add systemd-remount-fs to your After list?
    – Eric Renouf
    Dec 4 '15 at 19:13
















Does it work if you add systemd-remount-fs to your After list?
– Eric Renouf
Dec 4 '15 at 19:13




Does it work if you add systemd-remount-fs to your After list?
– Eric Renouf
Dec 4 '15 at 19:13










3 Answers
3






active

oldest

votes


















30





+50










a CIFS network location is mounted via /etc/fstab to /mnt/ on boot-up.




No, it is not. Get this right, and the rest falls into place naturally.



The mount is handled by a (generated) systemd mount unit that will be named something like mnt-wibble.mount. You can see its actual name in the output of the systemctl command. You can look at it in detail just like any other unit with systemctl status.



Very simply, then: you have to order your unit to be started after that mount unit is started.



After=network.target vpn-launch.service mnt-wibble.mount


Further reading




  • https://unix.stackexchange.com/a/236968/5132






share|improve this answer



















  • 5




    List mounts with "systemctl list-units --type=mount"
    – nijave
    Apr 5 at 17:10



















14














Sorry but I can't comment yet.



Like JdeBP said, you should be ordering on the filesystem mount. You can predict the name of the mount unit or, alternatively, you can use (in unit section):




RequiresMountsFor=/absolute/path/of/mount




This option creates the dependencies to the appropriate *.mount units to make the path accessible before starting the service. It may not be on all systemd versions, but I've been using it in a CentOS 7 machine for the last 6 months or so.






share|improve this answer





















  • (And your differences from vanilla systemd are here.) RequiresMountsFor= does come with its own set of caveats. With RedHat bug #1088057 and Chris Siebenmann in hand, you should be able to answer superuser.com/questions/988734 . It's a CIFS mount in this question, too. But the implication is that it is auto, fortunately.
    – JdeBP
    Dec 13 '15 at 6:19










  • @JdeBP Thank you for the comment. I wasn't aware of the caveats and issues on that feature.
    – miguelbernadi
    Dec 13 '15 at 15:56



















10














Although both answers are correct, I want to add my two cents to the discussion, because when I have looked for it I was missing some instructions and examples of how to proceed.




  1. Add the filesystem to /etc/fstab

  2. Type mount -a which mounts all filesystems mentioned in fstab

  3. Look for the systemd unit that has been generated with:

    systemctl list-units | grep '/path/to/mount' | awk '{ print $1 }'

    (should return something that ends with .mount)

  4. Add the found mount-unit to the After= statement in the *.service file





Here is an example of starting the my-daemon service on boot but after the network is ready, a CIFS share is mounted at /mnt/cifs, and the vpn-launch service has started:



/etc/fstab



//servername/sharename /mnt/cifs cifs defaults,some,other,options 0 0



/etc/systemd/system/my-daemon.service



[Unit]
Description=Launch My Daemon
Requires=vpn-launch.service
After=network.target vpn-launch.service mnt-cifs.mount

[Service]
ExecStart=/path/to/my-daemon

[Install]
WantedBy=multi-user.target


Do not forget to enable the service such that it is started on boot: systemctl enable my-daemon



Note that this works for other filesystems (NFS, HDDs, etc.) as well.



As already mentioned, both answers are correct and I encourage everybody to read them but for me a couple of examples would have saved me some time.






share|improve this answer























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "106"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f246935%2fset-systemd-service-to-execute-after-fstab-mount%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    30





    +50










    a CIFS network location is mounted via /etc/fstab to /mnt/ on boot-up.




    No, it is not. Get this right, and the rest falls into place naturally.



    The mount is handled by a (generated) systemd mount unit that will be named something like mnt-wibble.mount. You can see its actual name in the output of the systemctl command. You can look at it in detail just like any other unit with systemctl status.



    Very simply, then: you have to order your unit to be started after that mount unit is started.



    After=network.target vpn-launch.service mnt-wibble.mount


    Further reading




    • https://unix.stackexchange.com/a/236968/5132






    share|improve this answer



















    • 5




      List mounts with "systemctl list-units --type=mount"
      – nijave
      Apr 5 at 17:10
















    30





    +50










    a CIFS network location is mounted via /etc/fstab to /mnt/ on boot-up.




    No, it is not. Get this right, and the rest falls into place naturally.



    The mount is handled by a (generated) systemd mount unit that will be named something like mnt-wibble.mount. You can see its actual name in the output of the systemctl command. You can look at it in detail just like any other unit with systemctl status.



    Very simply, then: you have to order your unit to be started after that mount unit is started.



    After=network.target vpn-launch.service mnt-wibble.mount


    Further reading




    • https://unix.stackexchange.com/a/236968/5132






    share|improve this answer



















    • 5




      List mounts with "systemctl list-units --type=mount"
      – nijave
      Apr 5 at 17:10














    30





    +50







    30





    +50



    30




    +50





    a CIFS network location is mounted via /etc/fstab to /mnt/ on boot-up.




    No, it is not. Get this right, and the rest falls into place naturally.



    The mount is handled by a (generated) systemd mount unit that will be named something like mnt-wibble.mount. You can see its actual name in the output of the systemctl command. You can look at it in detail just like any other unit with systemctl status.



    Very simply, then: you have to order your unit to be started after that mount unit is started.



    After=network.target vpn-launch.service mnt-wibble.mount


    Further reading




    • https://unix.stackexchange.com/a/236968/5132






    share|improve this answer















    a CIFS network location is mounted via /etc/fstab to /mnt/ on boot-up.




    No, it is not. Get this right, and the rest falls into place naturally.



    The mount is handled by a (generated) systemd mount unit that will be named something like mnt-wibble.mount. You can see its actual name in the output of the systemctl command. You can look at it in detail just like any other unit with systemctl status.



    Very simply, then: you have to order your unit to be started after that mount unit is started.



    After=network.target vpn-launch.service mnt-wibble.mount


    Further reading




    • https://unix.stackexchange.com/a/236968/5132







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Apr 13 '17 at 12:37









    Community

    1




    1










    answered Dec 5 '15 at 15:28









    JdeBP

    33.2k468156




    33.2k468156








    • 5




      List mounts with "systemctl list-units --type=mount"
      – nijave
      Apr 5 at 17:10














    • 5




      List mounts with "systemctl list-units --type=mount"
      – nijave
      Apr 5 at 17:10








    5




    5




    List mounts with "systemctl list-units --type=mount"
    – nijave
    Apr 5 at 17:10




    List mounts with "systemctl list-units --type=mount"
    – nijave
    Apr 5 at 17:10













    14














    Sorry but I can't comment yet.



    Like JdeBP said, you should be ordering on the filesystem mount. You can predict the name of the mount unit or, alternatively, you can use (in unit section):




    RequiresMountsFor=/absolute/path/of/mount




    This option creates the dependencies to the appropriate *.mount units to make the path accessible before starting the service. It may not be on all systemd versions, but I've been using it in a CentOS 7 machine for the last 6 months or so.






    share|improve this answer





















    • (And your differences from vanilla systemd are here.) RequiresMountsFor= does come with its own set of caveats. With RedHat bug #1088057 and Chris Siebenmann in hand, you should be able to answer superuser.com/questions/988734 . It's a CIFS mount in this question, too. But the implication is that it is auto, fortunately.
      – JdeBP
      Dec 13 '15 at 6:19










    • @JdeBP Thank you for the comment. I wasn't aware of the caveats and issues on that feature.
      – miguelbernadi
      Dec 13 '15 at 15:56
















    14














    Sorry but I can't comment yet.



    Like JdeBP said, you should be ordering on the filesystem mount. You can predict the name of the mount unit or, alternatively, you can use (in unit section):




    RequiresMountsFor=/absolute/path/of/mount




    This option creates the dependencies to the appropriate *.mount units to make the path accessible before starting the service. It may not be on all systemd versions, but I've been using it in a CentOS 7 machine for the last 6 months or so.






    share|improve this answer





















    • (And your differences from vanilla systemd are here.) RequiresMountsFor= does come with its own set of caveats. With RedHat bug #1088057 and Chris Siebenmann in hand, you should be able to answer superuser.com/questions/988734 . It's a CIFS mount in this question, too. But the implication is that it is auto, fortunately.
      – JdeBP
      Dec 13 '15 at 6:19










    • @JdeBP Thank you for the comment. I wasn't aware of the caveats and issues on that feature.
      – miguelbernadi
      Dec 13 '15 at 15:56














    14












    14








    14






    Sorry but I can't comment yet.



    Like JdeBP said, you should be ordering on the filesystem mount. You can predict the name of the mount unit or, alternatively, you can use (in unit section):




    RequiresMountsFor=/absolute/path/of/mount




    This option creates the dependencies to the appropriate *.mount units to make the path accessible before starting the service. It may not be on all systemd versions, but I've been using it in a CentOS 7 machine for the last 6 months or so.






    share|improve this answer












    Sorry but I can't comment yet.



    Like JdeBP said, you should be ordering on the filesystem mount. You can predict the name of the mount unit or, alternatively, you can use (in unit section):




    RequiresMountsFor=/absolute/path/of/mount




    This option creates the dependencies to the appropriate *.mount units to make the path accessible before starting the service. It may not be on all systemd versions, but I've been using it in a CentOS 7 machine for the last 6 months or so.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Dec 11 '15 at 18:22









    miguelbernadi

    33114




    33114












    • (And your differences from vanilla systemd are here.) RequiresMountsFor= does come with its own set of caveats. With RedHat bug #1088057 and Chris Siebenmann in hand, you should be able to answer superuser.com/questions/988734 . It's a CIFS mount in this question, too. But the implication is that it is auto, fortunately.
      – JdeBP
      Dec 13 '15 at 6:19










    • @JdeBP Thank you for the comment. I wasn't aware of the caveats and issues on that feature.
      – miguelbernadi
      Dec 13 '15 at 15:56


















    • (And your differences from vanilla systemd are here.) RequiresMountsFor= does come with its own set of caveats. With RedHat bug #1088057 and Chris Siebenmann in hand, you should be able to answer superuser.com/questions/988734 . It's a CIFS mount in this question, too. But the implication is that it is auto, fortunately.
      – JdeBP
      Dec 13 '15 at 6:19










    • @JdeBP Thank you for the comment. I wasn't aware of the caveats and issues on that feature.
      – miguelbernadi
      Dec 13 '15 at 15:56
















    (And your differences from vanilla systemd are here.) RequiresMountsFor= does come with its own set of caveats. With RedHat bug #1088057 and Chris Siebenmann in hand, you should be able to answer superuser.com/questions/988734 . It's a CIFS mount in this question, too. But the implication is that it is auto, fortunately.
    – JdeBP
    Dec 13 '15 at 6:19




    (And your differences from vanilla systemd are here.) RequiresMountsFor= does come with its own set of caveats. With RedHat bug #1088057 and Chris Siebenmann in hand, you should be able to answer superuser.com/questions/988734 . It's a CIFS mount in this question, too. But the implication is that it is auto, fortunately.
    – JdeBP
    Dec 13 '15 at 6:19












    @JdeBP Thank you for the comment. I wasn't aware of the caveats and issues on that feature.
    – miguelbernadi
    Dec 13 '15 at 15:56




    @JdeBP Thank you for the comment. I wasn't aware of the caveats and issues on that feature.
    – miguelbernadi
    Dec 13 '15 at 15:56











    10














    Although both answers are correct, I want to add my two cents to the discussion, because when I have looked for it I was missing some instructions and examples of how to proceed.




    1. Add the filesystem to /etc/fstab

    2. Type mount -a which mounts all filesystems mentioned in fstab

    3. Look for the systemd unit that has been generated with:

      systemctl list-units | grep '/path/to/mount' | awk '{ print $1 }'

      (should return something that ends with .mount)

    4. Add the found mount-unit to the After= statement in the *.service file





    Here is an example of starting the my-daemon service on boot but after the network is ready, a CIFS share is mounted at /mnt/cifs, and the vpn-launch service has started:



    /etc/fstab



    //servername/sharename /mnt/cifs cifs defaults,some,other,options 0 0



    /etc/systemd/system/my-daemon.service



    [Unit]
    Description=Launch My Daemon
    Requires=vpn-launch.service
    After=network.target vpn-launch.service mnt-cifs.mount

    [Service]
    ExecStart=/path/to/my-daemon

    [Install]
    WantedBy=multi-user.target


    Do not forget to enable the service such that it is started on boot: systemctl enable my-daemon



    Note that this works for other filesystems (NFS, HDDs, etc.) as well.



    As already mentioned, both answers are correct and I encourage everybody to read them but for me a couple of examples would have saved me some time.






    share|improve this answer




























      10














      Although both answers are correct, I want to add my two cents to the discussion, because when I have looked for it I was missing some instructions and examples of how to proceed.




      1. Add the filesystem to /etc/fstab

      2. Type mount -a which mounts all filesystems mentioned in fstab

      3. Look for the systemd unit that has been generated with:

        systemctl list-units | grep '/path/to/mount' | awk '{ print $1 }'

        (should return something that ends with .mount)

      4. Add the found mount-unit to the After= statement in the *.service file





      Here is an example of starting the my-daemon service on boot but after the network is ready, a CIFS share is mounted at /mnt/cifs, and the vpn-launch service has started:



      /etc/fstab



      //servername/sharename /mnt/cifs cifs defaults,some,other,options 0 0



      /etc/systemd/system/my-daemon.service



      [Unit]
      Description=Launch My Daemon
      Requires=vpn-launch.service
      After=network.target vpn-launch.service mnt-cifs.mount

      [Service]
      ExecStart=/path/to/my-daemon

      [Install]
      WantedBy=multi-user.target


      Do not forget to enable the service such that it is started on boot: systemctl enable my-daemon



      Note that this works for other filesystems (NFS, HDDs, etc.) as well.



      As already mentioned, both answers are correct and I encourage everybody to read them but for me a couple of examples would have saved me some time.






      share|improve this answer


























        10












        10








        10






        Although both answers are correct, I want to add my two cents to the discussion, because when I have looked for it I was missing some instructions and examples of how to proceed.




        1. Add the filesystem to /etc/fstab

        2. Type mount -a which mounts all filesystems mentioned in fstab

        3. Look for the systemd unit that has been generated with:

          systemctl list-units | grep '/path/to/mount' | awk '{ print $1 }'

          (should return something that ends with .mount)

        4. Add the found mount-unit to the After= statement in the *.service file





        Here is an example of starting the my-daemon service on boot but after the network is ready, a CIFS share is mounted at /mnt/cifs, and the vpn-launch service has started:



        /etc/fstab



        //servername/sharename /mnt/cifs cifs defaults,some,other,options 0 0



        /etc/systemd/system/my-daemon.service



        [Unit]
        Description=Launch My Daemon
        Requires=vpn-launch.service
        After=network.target vpn-launch.service mnt-cifs.mount

        [Service]
        ExecStart=/path/to/my-daemon

        [Install]
        WantedBy=multi-user.target


        Do not forget to enable the service such that it is started on boot: systemctl enable my-daemon



        Note that this works for other filesystems (NFS, HDDs, etc.) as well.



        As already mentioned, both answers are correct and I encourage everybody to read them but for me a couple of examples would have saved me some time.






        share|improve this answer














        Although both answers are correct, I want to add my two cents to the discussion, because when I have looked for it I was missing some instructions and examples of how to proceed.




        1. Add the filesystem to /etc/fstab

        2. Type mount -a which mounts all filesystems mentioned in fstab

        3. Look for the systemd unit that has been generated with:

          systemctl list-units | grep '/path/to/mount' | awk '{ print $1 }'

          (should return something that ends with .mount)

        4. Add the found mount-unit to the After= statement in the *.service file





        Here is an example of starting the my-daemon service on boot but after the network is ready, a CIFS share is mounted at /mnt/cifs, and the vpn-launch service has started:



        /etc/fstab



        //servername/sharename /mnt/cifs cifs defaults,some,other,options 0 0



        /etc/systemd/system/my-daemon.service



        [Unit]
        Description=Launch My Daemon
        Requires=vpn-launch.service
        After=network.target vpn-launch.service mnt-cifs.mount

        [Service]
        ExecStart=/path/to/my-daemon

        [Install]
        WantedBy=multi-user.target


        Do not forget to enable the service such that it is started on boot: systemctl enable my-daemon



        Note that this works for other filesystems (NFS, HDDs, etc.) as well.



        As already mentioned, both answers are correct and I encourage everybody to read them but for me a couple of examples would have saved me some time.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Dec 20 '17 at 16:19

























        answered Dec 20 '17 at 16:06









        bm-bergmotte

        11115




        11115






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f246935%2fset-systemd-service-to-execute-after-fstab-mount%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Morgemoulin

            Scott Moir

            Souastre