How to define systemd “ConsistsOf” relationship
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.
barmay be started, stopped or reloaded without affectingfoo
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
add a comment |
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.
barmay be started, stopped or reloaded without affectingfoo
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
add a comment |
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.
barmay be started, stopped or reloaded without affectingfoo
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
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.
barmay be started, stopped or reloaded without affectingfoo
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
systemd
edited 11 hours ago
Stewart
asked 12 hours ago
StewartStewart
213110
213110
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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" directoryfoo.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.
Yes, this works great.
– Stewart
11 hours ago
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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" directoryfoo.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.
Yes, this works great.
– Stewart
11 hours ago
add a comment |
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" directoryfoo.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.
Yes, this works great.
– Stewart
11 hours ago
add a comment |
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" directoryfoo.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.
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" directoryfoo.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.
answered 11 hours ago
filbrandenfilbranden
9,53121343
9,53121343
Yes, this works great.
– Stewart
11 hours ago
add a comment |
Yes, this works great.
– Stewart
11 hours ago
Yes, this works great.
– Stewart
11 hours ago
Yes, this works great.
– Stewart
11 hours ago
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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