How to define systemd “ConsistsOf” relationshipMake systemd reload only single openvpn process and not...

What game did these black and yellow dice come from?

Plausible reason for gold-digging ant

Can we "borrow" our answers to populate our own websites?

Best way to strengthen a wheel?

When obtaining gender reassignment/plastic surgery overseas, is an emergency travel document required to return home?

Can 5 Aarakocra PCs summon an Air Elemental?

Boss asked me to sign a resignation paper without a date on it along with my new contract

Why do neural networks need so many training examples to perform?

The effect of fishing on total land area needed to feed an island settlement

Is there any risk in sharing info about technologies and products we use with a supplier?

Why do all the books in Game of Thrones library have their covers facing the back of the shelf?

How to remove from the data the rows of with fixed number of elements?

Is a new boolean field better than null reference when a value can be meaningfully absent?

Why is Agricola named as such?

How can the probability of a fumble decrease linearly with more dice?

Is there a lava-breathing lizard creature (that could be worshipped by a cult) in 5e?

Could an Apollo mission be possible if Moon would be Earth like?

How to define systemd "ConsistsOf" relationship

Calculate the true diameter of stars from photographic plate

Translation needed for 130 years old church document

Strange "DuckDuckGo dork" takes me to random website

A starship is travelling at 0.9c and collides with a small rock. Will it leave a clean hole through, or will more happen?

Has any human ever had the choice to leave Earth permanently?

Prioritising polygons in QGIS



How to define systemd “ConsistsOf” relationship


Make systemd reload only single openvpn process and not the whole groupAdding a systemd .service (Debian)mysql service restarted during user being connected lead to failing servicesystemd unit files - conditional argumentsWhy is systemd stopping service immediately after it is started?Instruct to execute an unit after completing another unit successfullysystemd: finish the execution of custom shell script before starting nginxConfusing systemd behaviour with OnFailure= and Restart=Stopping systemd unit together with another. Starting workssystemd not autorestarting the last docker container after it crashes or kill -9 or docker stop service













3















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





























    3















    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



























      3












      3








      3


      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 3 hours ago







      Stewart

















      asked 4 hours ago









      StewartStewart

      208110




      208110






















          1 Answer
          1






          active

          oldest

          votes


















          5














          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
            2 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









          5














          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
            2 hours ago
















          5














          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
            2 hours ago














          5












          5








          5







          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 3 hours ago









          filbrandenfilbranden

          9,51121343




          9,51121343













          • Yes, this works great.

            – Stewart
            2 hours ago



















          • Yes, this works great.

            – Stewart
            2 hours ago

















          Yes, this works great.

          – Stewart
          2 hours ago





          Yes, this works great.

          – Stewart
          2 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

          “%fieldName is a required field.”, in Magento2 REST API Call for GET Method Type The Next...

          How to change City field to a dropdown in Checkout step Magento 2Magento 2 : How to change UI field(s)...

          變成蝙蝠會怎樣? 參考資料 外部連結 导航菜单Thomas Nagel, "What is it like to be a...