Can I safely edit Nginx Systemd unit file (/lib/systemd/system/nginx.service) supplied by nginx package?
I've installed Nginx with apt install nginx on a Debian 9.2 host. It works fine, but looking in the Systemd journal with journalctl -u nginx, I get the hilarious:
Started A high performance web server and a reverse proxy server.
Turns out Systemd reuses the "Description" field in the "[Unit]" section of the unit file, and sure enough for /lib/systemd/system/nginx.service it says:
Description=A high performance web server and a reverse proxy server
Is this a joke by Debian Nginx maintainers or someone else? Even Systemd documentation at https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description= says:
Bad examples are "high-performance light-weight HTTP server" (too generic)
So I am thinking to edit the "Description" field to give it a more ehm, descriptive value, but I am not sure how this will work when I will be updating nginx package as part of system update or upgrade -- will I be warned of a conflict if another version of nginx.service is attempted installed? I know this is the case with package configuration files, does this also apply to other kinds of files from the package?
debian nginx systemd
edited Dec 4 at 20:36
fixer1234
17.8k144581
asked Nov 10 '17 at 21:51
amn
65731933
add a comment |
I've installed Nginx with apt install nginx on a Debian 9.2 host. It works fine, but looking in the Systemd journal with journalctl -u nginx, I get the hilarious:
Started A high performance web server and a reverse proxy server.
Turns out Systemd reuses the "Description" field in the "[Unit]" section of the unit file, and sure enough for /lib/systemd/system/nginx.service it says:
Description=A high performance web server and a reverse proxy server
Is this a joke by Debian Nginx maintainers or someone else? Even Systemd documentation at https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description= says:
Bad examples are "high-performance light-weight HTTP server" (too generic)
So I am thinking to edit the "Description" field to give it a more ehm, descriptive value, but I am not sure how this will work when I will be updating nginx package as part of system update or upgrade -- will I be warned of a conflict if another version of nginx.service is attempted installed? I know this is the case with package configuration files, does this also apply to other kinds of files from the package?
debian nginx systemd
edited Dec 4 at 20:36
fixer1234
17.8k144581
asked Nov 10 '17 at 21:51
amn
65731933
add a comment |
I've installed Nginx with apt install nginx on a Debian 9.2 host. It works fine, but looking in the Systemd journal with journalctl -u nginx, I get the hilarious:
Started A high performance web server and a reverse proxy server.
Turns out Systemd reuses the "Description" field in the "[Unit]" section of the unit file, and sure enough for /lib/systemd/system/nginx.service it says:
Description=A high performance web server and a reverse proxy server
Is this a joke by Debian Nginx maintainers or someone else? Even Systemd documentation at https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description= says:
Bad examples are "high-performance light-weight HTTP server" (too generic)
So I am thinking to edit the "Description" field to give it a more ehm, descriptive value, but I am not sure how this will work when I will be updating nginx package as part of system update or upgrade -- will I be warned of a conflict if another version of nginx.service is attempted installed? I know this is the case with package configuration files, does this also apply to other kinds of files from the package?
debian nginx systemd
edited Dec 4 at 20:36
fixer1234
17.8k144581
asked Nov 10 '17 at 21:51
amn
65731933
I've installed Nginx with apt install nginx on a Debian 9.2 host. It works fine, but looking in the Systemd journal with journalctl -u nginx, I get the hilarious:
Started A high performance web server and a reverse proxy server.
Turns out Systemd reuses the "Description" field in the "[Unit]" section of the unit file, and sure enough for /lib/systemd/system/nginx.service it says:
Description=A high performance web server and a reverse proxy server
Is this a joke by Debian Nginx maintainers or someone else? Even Systemd documentation at https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description= says:
Bad examples are "high-performance light-weight HTTP server" (too generic)
So I am thinking to edit the "Description" field to give it a more ehm, descriptive value, but I am not sure how this will work when I will be updating nginx package as part of system update or upgrade -- will I be warned of a conflict if another version of nginx.service is attempted installed? I know this is the case with package configuration files, does this also apply to other kinds of files from the package?
debian nginx systemd
debian nginx systemd
edited Dec 4 at 20:36
fixer1234
17.8k144581
asked Nov 10 '17 at 21:51
amn
65731933
edited Dec 4 at 20:36
fixer1234
17.8k144581
asked Nov 10 '17 at 21:51
amn
65731933
edited Dec 4 at 20:36
fixer1234
17.8k144581
edited Dec 4 at 20:36
fixer1234
17.8k144581
edited Dec 4 at 20:36
fixer1234
17.8k144581
17.8k144581
asked Nov 10 '17 at 21:51
amn
65731933
asked Nov 10 '17 at 21:51
amn
65731933
asked Nov 10 '17 at 21:51
amn
65731933
65731933
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
As a rough rule, anything in /usr or /lib should be considered read-only, and especially anything that was installed by a package. (There are rare unfortunate exceptions.) Unless a file was specially marked in the package, upgrades will simply overwrite it.
The recommended way of changing various systemd files is to copy them to /etc. For example, the unit file /etc/systemd/system/nginx.service will override the one in /usr/lib. (It will even override the autogenerated init.d service units.) Use the tool systemd-delta to see diffs of all overridden units.
Well, I say "recommended" because it also works with things like udev rules and such... But an even better method is to override just parts of a unit using "drop-in" files /etc/systemd/system/nginx.service.d/foobar.conf – this only needs two lines, the section name [Unit] and your new Description= setting; the rest will be inherited from /usr/lib.
In both cases you can use systemctl edit [--full] to just open an editor and make your changes.
Finally the generic Debian option is to tell the packaging system (dpkg) to avoid updating a specific file, no matter where it is located. You can "divert" the real file elsewhere using dpkg-divert. Other distros have similar features, e.g. Arch's pacman uses NoExtract= and NoUpgrade=.
answered Nov 10 '17 at 22:19
grawity
232k35490546
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
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%2fsuperuser.com%2fquestions%2f1267366%2fcan-i-safely-edit-nginx-systemd-unit-file-lib-systemd-system-nginx-service-su%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
As a rough rule, anything in /usr or /lib should be considered read-only, and especially anything that was installed by a package. (There are rare unfortunate exceptions.) Unless a file was specially marked in the package, upgrades will simply overwrite it.
The recommended way of changing various systemd files is to copy them to /etc. For example, the unit file /etc/systemd/system/nginx.service will override the one in /usr/lib. (It will even override the autogenerated init.d service units.) Use the tool systemd-delta to see diffs of all overridden units.
Well, I say "recommended" because it also works with things like udev rules and such... But an even better method is to override just parts of a unit using "drop-in" files /etc/systemd/system/nginx.service.d/foobar.conf – this only needs two lines, the section name [Unit] and your new Description= setting; the rest will be inherited from /usr/lib.
In both cases you can use systemctl edit [--full] to just open an editor and make your changes.
Finally the generic Debian option is to tell the packaging system (dpkg) to avoid updating a specific file, no matter where it is located. You can "divert" the real file elsewhere using dpkg-divert. Other distros have similar features, e.g. Arch's pacman uses NoExtract= and NoUpgrade=.
answered Nov 10 '17 at 22:19
grawity
232k35490546
add a comment |
As a rough rule, anything in /usr or /lib should be considered read-only, and especially anything that was installed by a package. (There are rare unfortunate exceptions.) Unless a file was specially marked in the package, upgrades will simply overwrite it.
The recommended way of changing various systemd files is to copy them to /etc. For example, the unit file /etc/systemd/system/nginx.service will override the one in /usr/lib. (It will even override the autogenerated init.d service units.) Use the tool systemd-delta to see diffs of all overridden units.
Well, I say "recommended" because it also works with things like udev rules and such... But an even better method is to override just parts of a unit using "drop-in" files /etc/systemd/system/nginx.service.d/foobar.conf – this only needs two lines, the section name [Unit] and your new Description= setting; the rest will be inherited from /usr/lib.
In both cases you can use systemctl edit [--full] to just open an editor and make your changes.
Finally the generic Debian option is to tell the packaging system (dpkg) to avoid updating a specific file, no matter where it is located. You can "divert" the real file elsewhere using dpkg-divert. Other distros have similar features, e.g. Arch's pacman uses NoExtract= and NoUpgrade=.
answered Nov 10 '17 at 22:19
grawity
232k35490546
add a comment |
As a rough rule, anything in /usr or /lib should be considered read-only, and especially anything that was installed by a package. (There are rare unfortunate exceptions.) Unless a file was specially marked in the package, upgrades will simply overwrite it.
The recommended way of changing various systemd files is to copy them to /etc. For example, the unit file /etc/systemd/system/nginx.service will override the one in /usr/lib. (It will even override the autogenerated init.d service units.) Use the tool systemd-delta to see diffs of all overridden units.
Well, I say "recommended" because it also works with things like udev rules and such... But an even better method is to override just parts of a unit using "drop-in" files /etc/systemd/system/nginx.service.d/foobar.conf – this only needs two lines, the section name [Unit] and your new Description= setting; the rest will be inherited from /usr/lib.
In both cases you can use systemctl edit [--full] to just open an editor and make your changes.
Finally the generic Debian option is to tell the packaging system (dpkg) to avoid updating a specific file, no matter where it is located. You can "divert" the real file elsewhere using dpkg-divert. Other distros have similar features, e.g. Arch's pacman uses NoExtract= and NoUpgrade=.
answered Nov 10 '17 at 22:19
grawity
232k35490546
As a rough rule, anything in /usr or /lib should be considered read-only, and especially anything that was installed by a package. (There are rare unfortunate exceptions.) Unless a file was specially marked in the package, upgrades will simply overwrite it.
The recommended way of changing various systemd files is to copy them to /etc. For example, the unit file /etc/systemd/system/nginx.service will override the one in /usr/lib. (It will even override the autogenerated init.d service units.) Use the tool systemd-delta to see diffs of all overridden units.
Well, I say "recommended" because it also works with things like udev rules and such... But an even better method is to override just parts of a unit using "drop-in" files /etc/systemd/system/nginx.service.d/foobar.conf – this only needs two lines, the section name [Unit] and your new Description= setting; the rest will be inherited from /usr/lib.
In both cases you can use systemctl edit [--full] to just open an editor and make your changes.
Finally the generic Debian option is to tell the packaging system (dpkg) to avoid updating a specific file, no matter where it is located. You can "divert" the real file elsewhere using dpkg-divert. Other distros have similar features, e.g. Arch's pacman uses NoExtract= and NoUpgrade=.
answered Nov 10 '17 at 22:19
grawity
232k35490546
answered Nov 10 '17 at 22:19
grawity
232k35490546
answered Nov 10 '17 at 22:19
grawity
232k35490546
answered Nov 10 '17 at 22:19
grawity
232k35490546
232k35490546
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- 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.
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%2fsuperuser.com%2fquestions%2f1267366%2fcan-i-safely-edit-nginx-systemd-unit-file-lib-systemd-system-nginx-service-su%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
