How to define systemd “ConsistsOf” relationship












4















I am creating a package foo which launches/closes upstream package bar. The relationship should be:




  • When you start foo, also start bar.

  • When to you stop/reload foo, also stop/reload bar.


  • bar may be started, stopped or reloaded without affecting foo


If /lib/systemd/system/bar.service looks like this:



[Unit]
Description=Bar

[Service]
ExecStart=/bin/sleep infinity
Restart=on-failure


Then then "normal" solution would be to add WantedBy and PartOf relationships to bar:



[Unit]
Description=Bar
PartOf=foo.service

[Service]
ExecStart=/bin/sleep infinity
Restart=on-failure

[Install]
WantedBy=foo.service


However, bar is an upstream package and I think it's not quite right to force bar to be aware of foo, or to patch bar.



I thought a perfect solution would be to create foo.service like this:



[Unit]
Description=Foo
Wants=bar.service
ConsistsOf=bar.service

[Service]
Type=oneshot
ExecStart=/bin/true
RemainAfterExit=yes


However my journalctl says:




Unknown lvalue 'ConsistsOf' in section 'Unit'




and man pages say:




When PartOf=b.service is used on a.service, this dependency will show as ConsistsOf=a.service in property listing of b.service. ConsistsOf= dependency cannot be specified directly.




I'm not sure why ConsistsOf= cannot be specified directly, but is there an alternative that I didn't consider?










share|improve this question





























    4















    I am creating a package foo which launches/closes upstream package bar. The relationship should be:




    • When you start foo, also start bar.

    • When to you stop/reload foo, also stop/reload bar.


    • bar may be started, stopped or reloaded without affecting foo


    If /lib/systemd/system/bar.service looks like this:



    [Unit]
    Description=Bar

    [Service]
    ExecStart=/bin/sleep infinity
    Restart=on-failure


    Then then "normal" solution would be to add WantedBy and PartOf relationships to bar:



    [Unit]
    Description=Bar
    PartOf=foo.service

    [Service]
    ExecStart=/bin/sleep infinity
    Restart=on-failure

    [Install]
    WantedBy=foo.service


    However, bar is an upstream package and I think it's not quite right to force bar to be aware of foo, or to patch bar.



    I thought a perfect solution would be to create foo.service like this:



    [Unit]
    Description=Foo
    Wants=bar.service
    ConsistsOf=bar.service

    [Service]
    Type=oneshot
    ExecStart=/bin/true
    RemainAfterExit=yes


    However my journalctl says:




    Unknown lvalue 'ConsistsOf' in section 'Unit'




    and man pages say:




    When PartOf=b.service is used on a.service, this dependency will show as ConsistsOf=a.service in property listing of b.service. ConsistsOf= dependency cannot be specified directly.




    I'm not sure why ConsistsOf= cannot be specified directly, but is there an alternative that I didn't consider?










    share|improve this question



























      4












      4








      4


      0






      I am creating a package foo which launches/closes upstream package bar. The relationship should be:




      • When you start foo, also start bar.

      • When to you stop/reload foo, also stop/reload bar.


      • bar may be started, stopped or reloaded without affecting foo


      If /lib/systemd/system/bar.service looks like this:



      [Unit]
      Description=Bar

      [Service]
      ExecStart=/bin/sleep infinity
      Restart=on-failure


      Then then "normal" solution would be to add WantedBy and PartOf relationships to bar:



      [Unit]
      Description=Bar
      PartOf=foo.service

      [Service]
      ExecStart=/bin/sleep infinity
      Restart=on-failure

      [Install]
      WantedBy=foo.service


      However, bar is an upstream package and I think it's not quite right to force bar to be aware of foo, or to patch bar.



      I thought a perfect solution would be to create foo.service like this:



      [Unit]
      Description=Foo
      Wants=bar.service
      ConsistsOf=bar.service

      [Service]
      Type=oneshot
      ExecStart=/bin/true
      RemainAfterExit=yes


      However my journalctl says:




      Unknown lvalue 'ConsistsOf' in section 'Unit'




      and man pages say:




      When PartOf=b.service is used on a.service, this dependency will show as ConsistsOf=a.service in property listing of b.service. ConsistsOf= dependency cannot be specified directly.




      I'm not sure why ConsistsOf= cannot be specified directly, but is there an alternative that I didn't consider?










      share|improve this question
















      I am creating a package foo which launches/closes upstream package bar. The relationship should be:




      • When you start foo, also start bar.

      • When to you stop/reload foo, also stop/reload bar.


      • bar may be started, stopped or reloaded without affecting foo


      If /lib/systemd/system/bar.service looks like this:



      [Unit]
      Description=Bar

      [Service]
      ExecStart=/bin/sleep infinity
      Restart=on-failure


      Then then "normal" solution would be to add WantedBy and PartOf relationships to bar:



      [Unit]
      Description=Bar
      PartOf=foo.service

      [Service]
      ExecStart=/bin/sleep infinity
      Restart=on-failure

      [Install]
      WantedBy=foo.service


      However, bar is an upstream package and I think it's not quite right to force bar to be aware of foo, or to patch bar.



      I thought a perfect solution would be to create foo.service like this:



      [Unit]
      Description=Foo
      Wants=bar.service
      ConsistsOf=bar.service

      [Service]
      Type=oneshot
      ExecStart=/bin/true
      RemainAfterExit=yes


      However my journalctl says:




      Unknown lvalue 'ConsistsOf' in section 'Unit'




      and man pages say:




      When PartOf=b.service is used on a.service, this dependency will show as ConsistsOf=a.service in property listing of b.service. ConsistsOf= dependency cannot be specified directly.




      I'm not sure why ConsistsOf= cannot be specified directly, but is there an alternative that I didn't consider?







      systemd






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 11 hours ago







      Stewart

















      asked 12 hours ago









      StewartStewart

      213110




      213110






















          1 Answer
          1






          active

          oldest

          votes


















          6














          The appropriate way to modify upstream/external bar.service to include a PartOf= relationship to another unit is to use a "drop-in" override config, which is a systemd feature allowing you to modify existing units without having to touch the original files.



          From systemd.unit man page:




          Along with a unit file foo.service, a "drop-in" directory foo.service.d/ may exist. All files with the suffix ".conf" from this directory will be parsed after the unit file itself is parsed. This is useful to alter or add configuration settings for a unit, without having to modify unit files.




          In your particular case, you should create a drop-in such as /etc/systemd/system/bar.service.d/partof-foo.conf, with contents:



          [Unit]
          PartOf=foo.service


          (The name partof-foo.conf is just a suggestion, anything with a .conf suffix should work.)



          Then reload the daemon with systemctl daemon-reload.



          After that is done, you can inspect the unit with systemctl cat bar, which will neatly show the override is being taken into account. Also, now, systemctl show foo will show a ConsistsOf= relationship to bar.service and the effects of that relationship will follow (stopping foo will cause bar to stop.)



          For the second part (foo having Wants=bar.service), I suggest adding that directive directly to foo.service instead of using an [Install] stanza in an "drop-in" for bar.service.



          For one, the [Install] section would have to be activated with a systemctl enable bar command, so in a way it's harder to maintain. (Also, I've seen bugs where [Install] from a "drop-in" is not respected. I believe these have been fixed, but might still exist in your distro's version of systemd.)



          Furthermore, you might want to use a stronger Requires= relationship, rather than Wants=, since that will make foo.service fail if bar.service can't be started. (Consider also adding an ordering dependency, such as After=bar.service from foo.service, so foo will actually wait until bar is up before doing its own startup.)



          Since foo.service is a file you control, simply include it there directly:



          [Unit]
          Description=Foo
          Requires=bar.service
          After=bar.service


          That's assuming you'll want the ordering dependency as well, it's safe to omit it if you don't.



          That should take care of everything.






          share|improve this answer
























          • Yes, this works great.

            – Stewart
            11 hours ago











          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%2f503138%2fhow-to-define-systemd-consistsof-relationship%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          6














          The appropriate way to modify upstream/external bar.service to include a PartOf= relationship to another unit is to use a "drop-in" override config, which is a systemd feature allowing you to modify existing units without having to touch the original files.



          From systemd.unit man page:




          Along with a unit file foo.service, a "drop-in" directory foo.service.d/ may exist. All files with the suffix ".conf" from this directory will be parsed after the unit file itself is parsed. This is useful to alter or add configuration settings for a unit, without having to modify unit files.




          In your particular case, you should create a drop-in such as /etc/systemd/system/bar.service.d/partof-foo.conf, with contents:



          [Unit]
          PartOf=foo.service


          (The name partof-foo.conf is just a suggestion, anything with a .conf suffix should work.)



          Then reload the daemon with systemctl daemon-reload.



          After that is done, you can inspect the unit with systemctl cat bar, which will neatly show the override is being taken into account. Also, now, systemctl show foo will show a ConsistsOf= relationship to bar.service and the effects of that relationship will follow (stopping foo will cause bar to stop.)



          For the second part (foo having Wants=bar.service), I suggest adding that directive directly to foo.service instead of using an [Install] stanza in an "drop-in" for bar.service.



          For one, the [Install] section would have to be activated with a systemctl enable bar command, so in a way it's harder to maintain. (Also, I've seen bugs where [Install] from a "drop-in" is not respected. I believe these have been fixed, but might still exist in your distro's version of systemd.)



          Furthermore, you might want to use a stronger Requires= relationship, rather than Wants=, since that will make foo.service fail if bar.service can't be started. (Consider also adding an ordering dependency, such as After=bar.service from foo.service, so foo will actually wait until bar is up before doing its own startup.)



          Since foo.service is a file you control, simply include it there directly:



          [Unit]
          Description=Foo
          Requires=bar.service
          After=bar.service


          That's assuming you'll want the ordering dependency as well, it's safe to omit it if you don't.



          That should take care of everything.






          share|improve this answer
























          • Yes, this works great.

            – Stewart
            11 hours ago
















          6














          The appropriate way to modify upstream/external bar.service to include a PartOf= relationship to another unit is to use a "drop-in" override config, which is a systemd feature allowing you to modify existing units without having to touch the original files.



          From systemd.unit man page:




          Along with a unit file foo.service, a "drop-in" directory foo.service.d/ may exist. All files with the suffix ".conf" from this directory will be parsed after the unit file itself is parsed. This is useful to alter or add configuration settings for a unit, without having to modify unit files.




          In your particular case, you should create a drop-in such as /etc/systemd/system/bar.service.d/partof-foo.conf, with contents:



          [Unit]
          PartOf=foo.service


          (The name partof-foo.conf is just a suggestion, anything with a .conf suffix should work.)



          Then reload the daemon with systemctl daemon-reload.



          After that is done, you can inspect the unit with systemctl cat bar, which will neatly show the override is being taken into account. Also, now, systemctl show foo will show a ConsistsOf= relationship to bar.service and the effects of that relationship will follow (stopping foo will cause bar to stop.)



          For the second part (foo having Wants=bar.service), I suggest adding that directive directly to foo.service instead of using an [Install] stanza in an "drop-in" for bar.service.



          For one, the [Install] section would have to be activated with a systemctl enable bar command, so in a way it's harder to maintain. (Also, I've seen bugs where [Install] from a "drop-in" is not respected. I believe these have been fixed, but might still exist in your distro's version of systemd.)



          Furthermore, you might want to use a stronger Requires= relationship, rather than Wants=, since that will make foo.service fail if bar.service can't be started. (Consider also adding an ordering dependency, such as After=bar.service from foo.service, so foo will actually wait until bar is up before doing its own startup.)



          Since foo.service is a file you control, simply include it there directly:



          [Unit]
          Description=Foo
          Requires=bar.service
          After=bar.service


          That's assuming you'll want the ordering dependency as well, it's safe to omit it if you don't.



          That should take care of everything.






          share|improve this answer
























          • Yes, this works great.

            – Stewart
            11 hours ago














          6












          6








          6







          The appropriate way to modify upstream/external bar.service to include a PartOf= relationship to another unit is to use a "drop-in" override config, which is a systemd feature allowing you to modify existing units without having to touch the original files.



          From systemd.unit man page:




          Along with a unit file foo.service, a "drop-in" directory foo.service.d/ may exist. All files with the suffix ".conf" from this directory will be parsed after the unit file itself is parsed. This is useful to alter or add configuration settings for a unit, without having to modify unit files.




          In your particular case, you should create a drop-in such as /etc/systemd/system/bar.service.d/partof-foo.conf, with contents:



          [Unit]
          PartOf=foo.service


          (The name partof-foo.conf is just a suggestion, anything with a .conf suffix should work.)



          Then reload the daemon with systemctl daemon-reload.



          After that is done, you can inspect the unit with systemctl cat bar, which will neatly show the override is being taken into account. Also, now, systemctl show foo will show a ConsistsOf= relationship to bar.service and the effects of that relationship will follow (stopping foo will cause bar to stop.)



          For the second part (foo having Wants=bar.service), I suggest adding that directive directly to foo.service instead of using an [Install] stanza in an "drop-in" for bar.service.



          For one, the [Install] section would have to be activated with a systemctl enable bar command, so in a way it's harder to maintain. (Also, I've seen bugs where [Install] from a "drop-in" is not respected. I believe these have been fixed, but might still exist in your distro's version of systemd.)



          Furthermore, you might want to use a stronger Requires= relationship, rather than Wants=, since that will make foo.service fail if bar.service can't be started. (Consider also adding an ordering dependency, such as After=bar.service from foo.service, so foo will actually wait until bar is up before doing its own startup.)



          Since foo.service is a file you control, simply include it there directly:



          [Unit]
          Description=Foo
          Requires=bar.service
          After=bar.service


          That's assuming you'll want the ordering dependency as well, it's safe to omit it if you don't.



          That should take care of everything.






          share|improve this answer













          The appropriate way to modify upstream/external bar.service to include a PartOf= relationship to another unit is to use a "drop-in" override config, which is a systemd feature allowing you to modify existing units without having to touch the original files.



          From systemd.unit man page:




          Along with a unit file foo.service, a "drop-in" directory foo.service.d/ may exist. All files with the suffix ".conf" from this directory will be parsed after the unit file itself is parsed. This is useful to alter or add configuration settings for a unit, without having to modify unit files.




          In your particular case, you should create a drop-in such as /etc/systemd/system/bar.service.d/partof-foo.conf, with contents:



          [Unit]
          PartOf=foo.service


          (The name partof-foo.conf is just a suggestion, anything with a .conf suffix should work.)



          Then reload the daemon with systemctl daemon-reload.



          After that is done, you can inspect the unit with systemctl cat bar, which will neatly show the override is being taken into account. Also, now, systemctl show foo will show a ConsistsOf= relationship to bar.service and the effects of that relationship will follow (stopping foo will cause bar to stop.)



          For the second part (foo having Wants=bar.service), I suggest adding that directive directly to foo.service instead of using an [Install] stanza in an "drop-in" for bar.service.



          For one, the [Install] section would have to be activated with a systemctl enable bar command, so in a way it's harder to maintain. (Also, I've seen bugs where [Install] from a "drop-in" is not respected. I believe these have been fixed, but might still exist in your distro's version of systemd.)



          Furthermore, you might want to use a stronger Requires= relationship, rather than Wants=, since that will make foo.service fail if bar.service can't be started. (Consider also adding an ordering dependency, such as After=bar.service from foo.service, so foo will actually wait until bar is up before doing its own startup.)



          Since foo.service is a file you control, simply include it there directly:



          [Unit]
          Description=Foo
          Requires=bar.service
          After=bar.service


          That's assuming you'll want the ordering dependency as well, it's safe to omit it if you don't.



          That should take care of everything.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered 11 hours ago









          filbrandenfilbranden

          9,53121343




          9,53121343













          • Yes, this works great.

            – Stewart
            11 hours ago



















          • Yes, this works great.

            – Stewart
            11 hours ago

















          Yes, this works great.

          – Stewart
          11 hours ago





          Yes, this works great.

          – Stewart
          11 hours ago


















          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.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f503138%2fhow-to-define-systemd-consistsof-relationship%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

          Paul Cézanne

          UIScrollView CustomStickyHeader Resize height generates problems when scroll is too fast

          Angular material date-picker (MatDatepicker) auto completes the date on focus out