Add /snap/bin to PATH used by systemd
I installed Docker via snap while setting up Ubuntu Server 18.10.
If I have a systemd unit file that references the docker command, I get this error:
Executable "docker" not found in path "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
I'm not sure where it is getting this search path. It does not match what is found in /etc/environment.
Without modifying the unit file, can I globally change the search path used by systemd to include /snap/bin?
On an Ubuntu 18.04 system, just using docker without the full path resulted in the error Executable path is not absolute. I ideally want the same service file to work with both snap's Docker and apt's docker-ce packages.
systemd snap
asked 6 hours ago
rgovrgov
1063
add a comment |
I installed Docker via snap while setting up Ubuntu Server 18.10.
If I have a systemd unit file that references the docker command, I get this error:
Executable "docker" not found in path "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
I'm not sure where it is getting this search path. It does not match what is found in /etc/environment.
Without modifying the unit file, can I globally change the search path used by systemd to include /snap/bin?
On an Ubuntu 18.04 system, just using docker without the full path resulted in the error Executable path is not absolute. I ideally want the same service file to work with both snap's Docker and apt's docker-ce packages.
systemd snap
asked 6 hours ago
rgovrgov
1063
If it complained about the relative path even when it found the command in its PATH, it really sounds like the better solution is to modify the unit file. That's also the more portable solution since you'll then be able to copy the unit file to another machine without needing to change systemd's path. Is that really not an option for you?
– terdon♦
2 hours ago
add a comment |
I installed Docker via snap while setting up Ubuntu Server 18.10.
If I have a systemd unit file that references the docker command, I get this error:
Executable "docker" not found in path "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
I'm not sure where it is getting this search path. It does not match what is found in /etc/environment.
Without modifying the unit file, can I globally change the search path used by systemd to include /snap/bin?
On an Ubuntu 18.04 system, just using docker without the full path resulted in the error Executable path is not absolute. I ideally want the same service file to work with both snap's Docker and apt's docker-ce packages.
systemd snap
asked 6 hours ago
rgovrgov
1063
I installed Docker via snap while setting up Ubuntu Server 18.10.
If I have a systemd unit file that references the docker command, I get this error:
Executable "docker" not found in path "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
I'm not sure where it is getting this search path. It does not match what is found in /etc/environment.
Without modifying the unit file, can I globally change the search path used by systemd to include /snap/bin?
On an Ubuntu 18.04 system, just using docker without the full path resulted in the error Executable path is not absolute. I ideally want the same service file to work with both snap's Docker and apt's docker-ce packages.
systemd snap
systemd snap
asked 6 hours ago
rgovrgov
1063
asked 6 hours ago
rgovrgov
1063
edited 4 hours ago
rgov
asked 6 hours ago
rgovrgov
1063
asked 6 hours ago
rgovrgov
1063
asked 6 hours ago
rgovrgov
1063
1063
If it complained about the relative path even when it found the command in its PATH, it really sounds like the better solution is to modify the unit file. That's also the more portable solution since you'll then be able to copy the unit file to another machine without needing to change systemd's path. Is that really not an option for you?
– terdon♦
2 hours ago
add a comment |
If it complained about the relative path even when it found the command in its PATH, it really sounds like the better solution is to modify the unit file. That's also the more portable solution since you'll then be able to copy the unit file to another machine without needing to change systemd's path. Is that really not an option for you?
– terdon♦
2 hours ago
If it complained about the relative path even when it found the command in its PATH, it really sounds like the better solution is to modify the unit file. That's also the more portable solution since you'll then be able to copy the unit file to another machine without needing to change systemd's path. Is that really not an option for you?
– terdon♦
2 hours ago
If it complained about the relative path even when it found the command in its PATH, it really sounds like the better solution is to modify the unit file. That's also the more portable solution since you'll then be able to copy the unit file to another machine without needing to change systemd's path. Is that really not an option for you?
– terdon♦
2 hours ago
add a comment |
1 Answer
1
active
oldest
votes
According to the systemd documentation, its PATH is set on compilation (see section "Command lines"):
If the command is not a full (absolute) path, it will be resolved to a full path using a fixed search path determinted at compilation time. Searched directories include /usr/local/bin/, /usr/bin/, /bin/ on systems using split /usr/bin/ and /bin/ directories, and their sbin/ counterparts on systems using split bin/ and sbin/. It is thus safe to use just the executable name in case of executables located in any of the "standard" directories, and an absolute path must be used in other cases. Using an absolute path is recommended to avoid ambiguity. Hint: this search path may be queried using systemd-path search-binaries-default.
The command to query the path on my Ubuntu 18.04 was sudo systemd-path search-binaries (on Arch, it was systemd-path search-binaries-default):
$ sudo systemd-path search-binaries
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
So, you have the following options:
The good: Edit the unit file so that it uses absolute paths. Assuming you have access to it, this is by far the best solution. It makes the file conform to the specification, it allows you to copy it to other machines, it even silences the warning messages.
The bad: Recompile systemd from source, and change the path. This is time consuming, complicated and, an all around bad idea unless you really know what you're doing. Even if you do, this seems lie a bad solution. You're not going to be able to recompile systemd every time you setup a new machine.
The ugly: If you really can't fix the unit file, you can always create a symlink in /usr/bin pointing to docker
sudo ln -s /snap/bin/docker /usr/bin/docker
answered 1 hour ago
terdon♦terdon
66.4k12138221
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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%2faskubuntu.com%2fquestions%2f1121495%2fadd-snap-bin-to-path-used-by-systemd%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
According to the systemd documentation, its PATH is set on compilation (see section "Command lines"):
If the command is not a full (absolute) path, it will be resolved to a full path using a fixed search path determinted at compilation time. Searched directories include /usr/local/bin/, /usr/bin/, /bin/ on systems using split /usr/bin/ and /bin/ directories, and their sbin/ counterparts on systems using split bin/ and sbin/. It is thus safe to use just the executable name in case of executables located in any of the "standard" directories, and an absolute path must be used in other cases. Using an absolute path is recommended to avoid ambiguity. Hint: this search path may be queried using systemd-path search-binaries-default.
The command to query the path on my Ubuntu 18.04 was sudo systemd-path search-binaries (on Arch, it was systemd-path search-binaries-default):
$ sudo systemd-path search-binaries
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
So, you have the following options:
The good: Edit the unit file so that it uses absolute paths. Assuming you have access to it, this is by far the best solution. It makes the file conform to the specification, it allows you to copy it to other machines, it even silences the warning messages.
The bad: Recompile systemd from source, and change the path. This is time consuming, complicated and, an all around bad idea unless you really know what you're doing. Even if you do, this seems lie a bad solution. You're not going to be able to recompile systemd every time you setup a new machine.
The ugly: If you really can't fix the unit file, you can always create a symlink in /usr/bin pointing to docker
sudo ln -s /snap/bin/docker /usr/bin/docker
answered 1 hour ago
terdon♦terdon
66.4k12138221
add a comment |
According to the systemd documentation, its PATH is set on compilation (see section "Command lines"):
If the command is not a full (absolute) path, it will be resolved to a full path using a fixed search path determinted at compilation time. Searched directories include /usr/local/bin/, /usr/bin/, /bin/ on systems using split /usr/bin/ and /bin/ directories, and their sbin/ counterparts on systems using split bin/ and sbin/. It is thus safe to use just the executable name in case of executables located in any of the "standard" directories, and an absolute path must be used in other cases. Using an absolute path is recommended to avoid ambiguity. Hint: this search path may be queried using systemd-path search-binaries-default.
The command to query the path on my Ubuntu 18.04 was sudo systemd-path search-binaries (on Arch, it was systemd-path search-binaries-default):
$ sudo systemd-path search-binaries
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
So, you have the following options:
The good: Edit the unit file so that it uses absolute paths. Assuming you have access to it, this is by far the best solution. It makes the file conform to the specification, it allows you to copy it to other machines, it even silences the warning messages.
The bad: Recompile systemd from source, and change the path. This is time consuming, complicated and, an all around bad idea unless you really know what you're doing. Even if you do, this seems lie a bad solution. You're not going to be able to recompile systemd every time you setup a new machine.
The ugly: If you really can't fix the unit file, you can always create a symlink in /usr/bin pointing to docker
sudo ln -s /snap/bin/docker /usr/bin/docker
answered 1 hour ago
terdon♦terdon
66.4k12138221
add a comment |
According to the systemd documentation, its PATH is set on compilation (see section "Command lines"):
If the command is not a full (absolute) path, it will be resolved to a full path using a fixed search path determinted at compilation time. Searched directories include /usr/local/bin/, /usr/bin/, /bin/ on systems using split /usr/bin/ and /bin/ directories, and their sbin/ counterparts on systems using split bin/ and sbin/. It is thus safe to use just the executable name in case of executables located in any of the "standard" directories, and an absolute path must be used in other cases. Using an absolute path is recommended to avoid ambiguity. Hint: this search path may be queried using systemd-path search-binaries-default.
The command to query the path on my Ubuntu 18.04 was sudo systemd-path search-binaries (on Arch, it was systemd-path search-binaries-default):
$ sudo systemd-path search-binaries
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
So, you have the following options:
The good: Edit the unit file so that it uses absolute paths. Assuming you have access to it, this is by far the best solution. It makes the file conform to the specification, it allows you to copy it to other machines, it even silences the warning messages.
The bad: Recompile systemd from source, and change the path. This is time consuming, complicated and, an all around bad idea unless you really know what you're doing. Even if you do, this seems lie a bad solution. You're not going to be able to recompile systemd every time you setup a new machine.
The ugly: If you really can't fix the unit file, you can always create a symlink in /usr/bin pointing to docker
sudo ln -s /snap/bin/docker /usr/bin/docker
answered 1 hour ago
terdon♦terdon
66.4k12138221
According to the systemd documentation, its PATH is set on compilation (see section "Command lines"):
If the command is not a full (absolute) path, it will be resolved to a full path using a fixed search path determinted at compilation time. Searched directories include /usr/local/bin/, /usr/bin/, /bin/ on systems using split /usr/bin/ and /bin/ directories, and their sbin/ counterparts on systems using split bin/ and sbin/. It is thus safe to use just the executable name in case of executables located in any of the "standard" directories, and an absolute path must be used in other cases. Using an absolute path is recommended to avoid ambiguity. Hint: this search path may be queried using systemd-path search-binaries-default.
The command to query the path on my Ubuntu 18.04 was sudo systemd-path search-binaries (on Arch, it was systemd-path search-binaries-default):
$ sudo systemd-path search-binaries
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
So, you have the following options:
The good: Edit the unit file so that it uses absolute paths. Assuming you have access to it, this is by far the best solution. It makes the file conform to the specification, it allows you to copy it to other machines, it even silences the warning messages.
The bad: Recompile systemd from source, and change the path. This is time consuming, complicated and, an all around bad idea unless you really know what you're doing. Even if you do, this seems lie a bad solution. You're not going to be able to recompile systemd every time you setup a new machine.
The ugly: If you really can't fix the unit file, you can always create a symlink in /usr/bin pointing to docker
sudo ln -s /snap/bin/docker /usr/bin/docker
answered 1 hour ago
terdon♦terdon
66.4k12138221
answered 1 hour ago
terdon♦terdon
66.4k12138221
answered 1 hour ago
terdon♦terdon
66.4k12138221
answered 1 hour ago
terdon♦terdon
66.4k12138221
66.4k12138221
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- 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%2faskubuntu.com%2fquestions%2f1121495%2fadd-snap-bin-to-path-used-by-systemd%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
If it complained about the relative path even when it found the command in its PATH, it really sounds like the better solution is to modify the unit file. That's also the more portable solution since you'll then be able to copy the unit file to another machine without needing to change systemd's path. Is that really not an option for you?
– terdon♦
2 hours ago