Using systemctl edit via bash script?
up vote
2
down vote
favorite
I install Debian a lot. To do this I have a fully-automated preseed.cfg; at the end of the preseed, it downloads and runs a postinstall.sh script from my TFTP server, which does some additional customization.
I'm in the process of switching from GNOME to LXQTE, and using SDDM instead of GDM. However, SDDM tries to start too quickly for my hardware. To get around this, I've been using systemctl edit sddm
to add the following:
[Service]
ExecStartPre=/bin/sleep 5
This works great, and I'd like to automate this process by adding it to the postinstall.sh script. However, I can't figure out how to pass the file contents to systemctl edit
via a bash script. How can I do this?
shell-script systemd startup
add a comment |
up vote
2
down vote
favorite
I install Debian a lot. To do this I have a fully-automated preseed.cfg; at the end of the preseed, it downloads and runs a postinstall.sh script from my TFTP server, which does some additional customization.
I'm in the process of switching from GNOME to LXQTE, and using SDDM instead of GDM. However, SDDM tries to start too quickly for my hardware. To get around this, I've been using systemctl edit sddm
to add the following:
[Service]
ExecStartPre=/bin/sleep 5
This works great, and I'd like to automate this process by adding it to the postinstall.sh script. However, I can't figure out how to pass the file contents to systemctl edit
via a bash script. How can I do this?
shell-script systemd startup
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I install Debian a lot. To do this I have a fully-automated preseed.cfg; at the end of the preseed, it downloads and runs a postinstall.sh script from my TFTP server, which does some additional customization.
I'm in the process of switching from GNOME to LXQTE, and using SDDM instead of GDM. However, SDDM tries to start too quickly for my hardware. To get around this, I've been using systemctl edit sddm
to add the following:
[Service]
ExecStartPre=/bin/sleep 5
This works great, and I'd like to automate this process by adding it to the postinstall.sh script. However, I can't figure out how to pass the file contents to systemctl edit
via a bash script. How can I do this?
shell-script systemd startup
I install Debian a lot. To do this I have a fully-automated preseed.cfg; at the end of the preseed, it downloads and runs a postinstall.sh script from my TFTP server, which does some additional customization.
I'm in the process of switching from GNOME to LXQTE, and using SDDM instead of GDM. However, SDDM tries to start too quickly for my hardware. To get around this, I've been using systemctl edit sddm
to add the following:
[Service]
ExecStartPre=/bin/sleep 5
This works great, and I'd like to automate this process by adding it to the postinstall.sh script. However, I can't figure out how to pass the file contents to systemctl edit
via a bash script. How can I do this?
shell-script systemd startup
shell-script systemd startup
edited Aug 1 at 22:39
don_crissti
49.2k15129158
49.2k15129158
asked Aug 1 at 21:32
user5104897
139112
139112
add a comment |
add a comment |
4 Answers
4
active
oldest
votes
up vote
3
down vote
accepted
You can override the $SYSTEMD_EDITOR
environment variable to use a different command other than your editor when running systemctl edit
.
For instance, using something like SYSTEMD_EDITOR='cp /path/to/source.file'
seems to work OK (even though it's pretty ugly, expecting the last argument to be appended there by systemd!)
For your particular case, you could use:
$ { echo "[Service]";
echo "ExecStartPre=/bin/sleep 5";
} >~/tmp/sddm-override.conf
$ sudo env SYSTEMD_EDITOR="cp $HOME/tmp/sddm-override.conf" systemctl edit sddm
But all that systemctl edit
really does is create an override file (in its case, named override.conf
) under the /etc/systemd/system/<service>.service.d/
directory, which is created if it does not exist... So doing that directly is also a totally accepted approach. (See mentions of "drop-in" and "override" in the man page for systemd.unit for more details.)
So, in your case, this would be an appropriate solution:
$ sudo mkdir -p /etc/systemd/system/sddm.service.d/
$ { echo "[Service]";
echo "ExecStartPre=/bin/sleep 5";
} | sudo tee /etc/systemd/system/sddm.service.d/10-startup-delay.conf
$ sudo systemctl daemon-reload
Which drops a file with the expected contents in the "drop-in" directory for your unit, in which case you can also name it appropriately after what it tries to accomplish.
UPDATED: As @GracefulRestart points out, you need a systemctl daemon-reload
after adding a drop-in directly.
Thank you for your answer, but I haven't had any luck with it. See my comment to @GracefulRestart; basically thesddm.service.d
directory is not created on install, and even manually creating it and theoverride.conf
does not work (even withdaemon-reload
) - there must be something special about thesystemctl edit
in particular.
– user5104897
Aug 2 at 18:02
@user5104897 If you think there's something special withsystemctl edit
then try the first method I suggested of setting SYSTEMD_EDITOR environment variable to a command that will create the file. I think the issue might actually be with your postinstall script. Are you running that in the root directory at the machine, or is it maybe running from install media and so you're modifying that filesystem and not the one you boot into? Can you give more details on what your postinstall script is and does? Good luck!
– Filipe Brandenburger
Aug 2 at 20:31
1
Ah, I was able to get it working with a few changes to the script - I forgot to~/tmp
- we're all good now!
– user5104897
Aug 3 at 17:03
add a comment |
up vote
4
down vote
Since I have not found how to use systemctl edit
in a script yet, best practice would be to simulate the systemctl edit sddm
command and place the override in the /etc/systemd/system directory, as service units in /usr/lib/systemd/system could be changed when packages are upgraded:
UNIT='sddm.service'
DIR="/etc/systemd/system/${UNIT}.d"
mkdir $DIR
echo -e "[Service]nExecStartPre=/bin/sleep 5" > ${DIR}/override.conf
systemctl daemon-reload
That should be roughly equivalent to what systemctl edit sddm
is doing.
I've tried this solution, but I'm running into some problems. After adding this to my postinstall script, sddm still didn't start as expected. I logged in and noticed the/etc/systemd/system/sddm.service.d
directory did not exist. After creating this directory and running theecho
anddaemon-reload
myself, I rebooted and it still didn't work. Next I tried addingmkdir /etc/systemd/system/sddm.service.d
to the postinstall, and this directory still isn't being created! Regardless, doing it manually doesn't seem to work either.
– user5104897
Aug 2 at 17:41
When you usesystemctl edit sddm
, where does systemd put the override.conf? I am not sure why you would not be able to create the directory, check permissions or if selinux is stopping you.
– GracefulRestart
Aug 2 at 19:57
I'm able to create the directory and file manually, but they have no effect even afterdaemon-reload
- it's only when I usesystemctl edit sddm
that the changes actually take effect. Usingsystemctl
opens a buffer named/etc/systemd/system/sddm.service.d/.#override.conf52ea69f0b57f34f9
, but it does ultimately createsddm.service.d/override.conf
anyway.
– user5104897
Aug 2 at 20:45
add a comment |
up vote
0
down vote
I want to second the answer given in 3 but I do it this way using tee
env SYSTEMD_EDITOR=tee sudo -E systemctl edit --system [your_unit_name] < [your_content_file]
When doing it this way you can feed the content via stdin rather than from a file, which can be useful when invoking systemctl from a script.
New contributor
add a comment |
up vote
-2
down vote
I'd attack the file directly:
sed -i 's/[Service]/ a
ExecStartPre=/bin/sleep 5' /usr/lib/systemd/system/sddm.service
1
editing files managed by a package is generally unreliable. An override would probably be a better option.
– smokes2345
Aug 1 at 22:36
This is incorrect. You shouldn't edit units from/usr/lib
directly, since the modifications are probably going to get clobbered next time the package is upgraded. Furthermore, what you suggest is likely to cause syntax errors, since the unit probably already has a[Service]
section and shouldn't really get another. Drop-ins are the correct way to deal with this kind of overrides. See the other answers for more details.
– Filipe Brandenburger
Aug 1 at 22:37
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',
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%2f459942%2fusing-systemctl-edit-via-bash-script%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
You can override the $SYSTEMD_EDITOR
environment variable to use a different command other than your editor when running systemctl edit
.
For instance, using something like SYSTEMD_EDITOR='cp /path/to/source.file'
seems to work OK (even though it's pretty ugly, expecting the last argument to be appended there by systemd!)
For your particular case, you could use:
$ { echo "[Service]";
echo "ExecStartPre=/bin/sleep 5";
} >~/tmp/sddm-override.conf
$ sudo env SYSTEMD_EDITOR="cp $HOME/tmp/sddm-override.conf" systemctl edit sddm
But all that systemctl edit
really does is create an override file (in its case, named override.conf
) under the /etc/systemd/system/<service>.service.d/
directory, which is created if it does not exist... So doing that directly is also a totally accepted approach. (See mentions of "drop-in" and "override" in the man page for systemd.unit for more details.)
So, in your case, this would be an appropriate solution:
$ sudo mkdir -p /etc/systemd/system/sddm.service.d/
$ { echo "[Service]";
echo "ExecStartPre=/bin/sleep 5";
} | sudo tee /etc/systemd/system/sddm.service.d/10-startup-delay.conf
$ sudo systemctl daemon-reload
Which drops a file with the expected contents in the "drop-in" directory for your unit, in which case you can also name it appropriately after what it tries to accomplish.
UPDATED: As @GracefulRestart points out, you need a systemctl daemon-reload
after adding a drop-in directly.
Thank you for your answer, but I haven't had any luck with it. See my comment to @GracefulRestart; basically thesddm.service.d
directory is not created on install, and even manually creating it and theoverride.conf
does not work (even withdaemon-reload
) - there must be something special about thesystemctl edit
in particular.
– user5104897
Aug 2 at 18:02
@user5104897 If you think there's something special withsystemctl edit
then try the first method I suggested of setting SYSTEMD_EDITOR environment variable to a command that will create the file. I think the issue might actually be with your postinstall script. Are you running that in the root directory at the machine, or is it maybe running from install media and so you're modifying that filesystem and not the one you boot into? Can you give more details on what your postinstall script is and does? Good luck!
– Filipe Brandenburger
Aug 2 at 20:31
1
Ah, I was able to get it working with a few changes to the script - I forgot to~/tmp
- we're all good now!
– user5104897
Aug 3 at 17:03
add a comment |
up vote
3
down vote
accepted
You can override the $SYSTEMD_EDITOR
environment variable to use a different command other than your editor when running systemctl edit
.
For instance, using something like SYSTEMD_EDITOR='cp /path/to/source.file'
seems to work OK (even though it's pretty ugly, expecting the last argument to be appended there by systemd!)
For your particular case, you could use:
$ { echo "[Service]";
echo "ExecStartPre=/bin/sleep 5";
} >~/tmp/sddm-override.conf
$ sudo env SYSTEMD_EDITOR="cp $HOME/tmp/sddm-override.conf" systemctl edit sddm
But all that systemctl edit
really does is create an override file (in its case, named override.conf
) under the /etc/systemd/system/<service>.service.d/
directory, which is created if it does not exist... So doing that directly is also a totally accepted approach. (See mentions of "drop-in" and "override" in the man page for systemd.unit for more details.)
So, in your case, this would be an appropriate solution:
$ sudo mkdir -p /etc/systemd/system/sddm.service.d/
$ { echo "[Service]";
echo "ExecStartPre=/bin/sleep 5";
} | sudo tee /etc/systemd/system/sddm.service.d/10-startup-delay.conf
$ sudo systemctl daemon-reload
Which drops a file with the expected contents in the "drop-in" directory for your unit, in which case you can also name it appropriately after what it tries to accomplish.
UPDATED: As @GracefulRestart points out, you need a systemctl daemon-reload
after adding a drop-in directly.
Thank you for your answer, but I haven't had any luck with it. See my comment to @GracefulRestart; basically thesddm.service.d
directory is not created on install, and even manually creating it and theoverride.conf
does not work (even withdaemon-reload
) - there must be something special about thesystemctl edit
in particular.
– user5104897
Aug 2 at 18:02
@user5104897 If you think there's something special withsystemctl edit
then try the first method I suggested of setting SYSTEMD_EDITOR environment variable to a command that will create the file. I think the issue might actually be with your postinstall script. Are you running that in the root directory at the machine, or is it maybe running from install media and so you're modifying that filesystem and not the one you boot into? Can you give more details on what your postinstall script is and does? Good luck!
– Filipe Brandenburger
Aug 2 at 20:31
1
Ah, I was able to get it working with a few changes to the script - I forgot to~/tmp
- we're all good now!
– user5104897
Aug 3 at 17:03
add a comment |
up vote
3
down vote
accepted
up vote
3
down vote
accepted
You can override the $SYSTEMD_EDITOR
environment variable to use a different command other than your editor when running systemctl edit
.
For instance, using something like SYSTEMD_EDITOR='cp /path/to/source.file'
seems to work OK (even though it's pretty ugly, expecting the last argument to be appended there by systemd!)
For your particular case, you could use:
$ { echo "[Service]";
echo "ExecStartPre=/bin/sleep 5";
} >~/tmp/sddm-override.conf
$ sudo env SYSTEMD_EDITOR="cp $HOME/tmp/sddm-override.conf" systemctl edit sddm
But all that systemctl edit
really does is create an override file (in its case, named override.conf
) under the /etc/systemd/system/<service>.service.d/
directory, which is created if it does not exist... So doing that directly is also a totally accepted approach. (See mentions of "drop-in" and "override" in the man page for systemd.unit for more details.)
So, in your case, this would be an appropriate solution:
$ sudo mkdir -p /etc/systemd/system/sddm.service.d/
$ { echo "[Service]";
echo "ExecStartPre=/bin/sleep 5";
} | sudo tee /etc/systemd/system/sddm.service.d/10-startup-delay.conf
$ sudo systemctl daemon-reload
Which drops a file with the expected contents in the "drop-in" directory for your unit, in which case you can also name it appropriately after what it tries to accomplish.
UPDATED: As @GracefulRestart points out, you need a systemctl daemon-reload
after adding a drop-in directly.
You can override the $SYSTEMD_EDITOR
environment variable to use a different command other than your editor when running systemctl edit
.
For instance, using something like SYSTEMD_EDITOR='cp /path/to/source.file'
seems to work OK (even though it's pretty ugly, expecting the last argument to be appended there by systemd!)
For your particular case, you could use:
$ { echo "[Service]";
echo "ExecStartPre=/bin/sleep 5";
} >~/tmp/sddm-override.conf
$ sudo env SYSTEMD_EDITOR="cp $HOME/tmp/sddm-override.conf" systemctl edit sddm
But all that systemctl edit
really does is create an override file (in its case, named override.conf
) under the /etc/systemd/system/<service>.service.d/
directory, which is created if it does not exist... So doing that directly is also a totally accepted approach. (See mentions of "drop-in" and "override" in the man page for systemd.unit for more details.)
So, in your case, this would be an appropriate solution:
$ sudo mkdir -p /etc/systemd/system/sddm.service.d/
$ { echo "[Service]";
echo "ExecStartPre=/bin/sleep 5";
} | sudo tee /etc/systemd/system/sddm.service.d/10-startup-delay.conf
$ sudo systemctl daemon-reload
Which drops a file with the expected contents in the "drop-in" directory for your unit, in which case you can also name it appropriately after what it tries to accomplish.
UPDATED: As @GracefulRestart points out, you need a systemctl daemon-reload
after adding a drop-in directly.
answered Aug 1 at 22:33
Filipe Brandenburger
6,8352733
6,8352733
Thank you for your answer, but I haven't had any luck with it. See my comment to @GracefulRestart; basically thesddm.service.d
directory is not created on install, and even manually creating it and theoverride.conf
does not work (even withdaemon-reload
) - there must be something special about thesystemctl edit
in particular.
– user5104897
Aug 2 at 18:02
@user5104897 If you think there's something special withsystemctl edit
then try the first method I suggested of setting SYSTEMD_EDITOR environment variable to a command that will create the file. I think the issue might actually be with your postinstall script. Are you running that in the root directory at the machine, or is it maybe running from install media and so you're modifying that filesystem and not the one you boot into? Can you give more details on what your postinstall script is and does? Good luck!
– Filipe Brandenburger
Aug 2 at 20:31
1
Ah, I was able to get it working with a few changes to the script - I forgot to~/tmp
- we're all good now!
– user5104897
Aug 3 at 17:03
add a comment |
Thank you for your answer, but I haven't had any luck with it. See my comment to @GracefulRestart; basically thesddm.service.d
directory is not created on install, and even manually creating it and theoverride.conf
does not work (even withdaemon-reload
) - there must be something special about thesystemctl edit
in particular.
– user5104897
Aug 2 at 18:02
@user5104897 If you think there's something special withsystemctl edit
then try the first method I suggested of setting SYSTEMD_EDITOR environment variable to a command that will create the file. I think the issue might actually be with your postinstall script. Are you running that in the root directory at the machine, or is it maybe running from install media and so you're modifying that filesystem and not the one you boot into? Can you give more details on what your postinstall script is and does? Good luck!
– Filipe Brandenburger
Aug 2 at 20:31
1
Ah, I was able to get it working with a few changes to the script - I forgot to~/tmp
- we're all good now!
– user5104897
Aug 3 at 17:03
Thank you for your answer, but I haven't had any luck with it. See my comment to @GracefulRestart; basically the
sddm.service.d
directory is not created on install, and even manually creating it and the override.conf
does not work (even with daemon-reload
) - there must be something special about the systemctl edit
in particular.– user5104897
Aug 2 at 18:02
Thank you for your answer, but I haven't had any luck with it. See my comment to @GracefulRestart; basically the
sddm.service.d
directory is not created on install, and even manually creating it and the override.conf
does not work (even with daemon-reload
) - there must be something special about the systemctl edit
in particular.– user5104897
Aug 2 at 18:02
@user5104897 If you think there's something special with
systemctl edit
then try the first method I suggested of setting SYSTEMD_EDITOR environment variable to a command that will create the file. I think the issue might actually be with your postinstall script. Are you running that in the root directory at the machine, or is it maybe running from install media and so you're modifying that filesystem and not the one you boot into? Can you give more details on what your postinstall script is and does? Good luck!– Filipe Brandenburger
Aug 2 at 20:31
@user5104897 If you think there's something special with
systemctl edit
then try the first method I suggested of setting SYSTEMD_EDITOR environment variable to a command that will create the file. I think the issue might actually be with your postinstall script. Are you running that in the root directory at the machine, or is it maybe running from install media and so you're modifying that filesystem and not the one you boot into? Can you give more details on what your postinstall script is and does? Good luck!– Filipe Brandenburger
Aug 2 at 20:31
1
1
Ah, I was able to get it working with a few changes to the script - I forgot to
~/tmp
- we're all good now!– user5104897
Aug 3 at 17:03
Ah, I was able to get it working with a few changes to the script - I forgot to
~/tmp
- we're all good now!– user5104897
Aug 3 at 17:03
add a comment |
up vote
4
down vote
Since I have not found how to use systemctl edit
in a script yet, best practice would be to simulate the systemctl edit sddm
command and place the override in the /etc/systemd/system directory, as service units in /usr/lib/systemd/system could be changed when packages are upgraded:
UNIT='sddm.service'
DIR="/etc/systemd/system/${UNIT}.d"
mkdir $DIR
echo -e "[Service]nExecStartPre=/bin/sleep 5" > ${DIR}/override.conf
systemctl daemon-reload
That should be roughly equivalent to what systemctl edit sddm
is doing.
I've tried this solution, but I'm running into some problems. After adding this to my postinstall script, sddm still didn't start as expected. I logged in and noticed the/etc/systemd/system/sddm.service.d
directory did not exist. After creating this directory and running theecho
anddaemon-reload
myself, I rebooted and it still didn't work. Next I tried addingmkdir /etc/systemd/system/sddm.service.d
to the postinstall, and this directory still isn't being created! Regardless, doing it manually doesn't seem to work either.
– user5104897
Aug 2 at 17:41
When you usesystemctl edit sddm
, where does systemd put the override.conf? I am not sure why you would not be able to create the directory, check permissions or if selinux is stopping you.
– GracefulRestart
Aug 2 at 19:57
I'm able to create the directory and file manually, but they have no effect even afterdaemon-reload
- it's only when I usesystemctl edit sddm
that the changes actually take effect. Usingsystemctl
opens a buffer named/etc/systemd/system/sddm.service.d/.#override.conf52ea69f0b57f34f9
, but it does ultimately createsddm.service.d/override.conf
anyway.
– user5104897
Aug 2 at 20:45
add a comment |
up vote
4
down vote
Since I have not found how to use systemctl edit
in a script yet, best practice would be to simulate the systemctl edit sddm
command and place the override in the /etc/systemd/system directory, as service units in /usr/lib/systemd/system could be changed when packages are upgraded:
UNIT='sddm.service'
DIR="/etc/systemd/system/${UNIT}.d"
mkdir $DIR
echo -e "[Service]nExecStartPre=/bin/sleep 5" > ${DIR}/override.conf
systemctl daemon-reload
That should be roughly equivalent to what systemctl edit sddm
is doing.
I've tried this solution, but I'm running into some problems. After adding this to my postinstall script, sddm still didn't start as expected. I logged in and noticed the/etc/systemd/system/sddm.service.d
directory did not exist. After creating this directory and running theecho
anddaemon-reload
myself, I rebooted and it still didn't work. Next I tried addingmkdir /etc/systemd/system/sddm.service.d
to the postinstall, and this directory still isn't being created! Regardless, doing it manually doesn't seem to work either.
– user5104897
Aug 2 at 17:41
When you usesystemctl edit sddm
, where does systemd put the override.conf? I am not sure why you would not be able to create the directory, check permissions or if selinux is stopping you.
– GracefulRestart
Aug 2 at 19:57
I'm able to create the directory and file manually, but they have no effect even afterdaemon-reload
- it's only when I usesystemctl edit sddm
that the changes actually take effect. Usingsystemctl
opens a buffer named/etc/systemd/system/sddm.service.d/.#override.conf52ea69f0b57f34f9
, but it does ultimately createsddm.service.d/override.conf
anyway.
– user5104897
Aug 2 at 20:45
add a comment |
up vote
4
down vote
up vote
4
down vote
Since I have not found how to use systemctl edit
in a script yet, best practice would be to simulate the systemctl edit sddm
command and place the override in the /etc/systemd/system directory, as service units in /usr/lib/systemd/system could be changed when packages are upgraded:
UNIT='sddm.service'
DIR="/etc/systemd/system/${UNIT}.d"
mkdir $DIR
echo -e "[Service]nExecStartPre=/bin/sleep 5" > ${DIR}/override.conf
systemctl daemon-reload
That should be roughly equivalent to what systemctl edit sddm
is doing.
Since I have not found how to use systemctl edit
in a script yet, best practice would be to simulate the systemctl edit sddm
command and place the override in the /etc/systemd/system directory, as service units in /usr/lib/systemd/system could be changed when packages are upgraded:
UNIT='sddm.service'
DIR="/etc/systemd/system/${UNIT}.d"
mkdir $DIR
echo -e "[Service]nExecStartPre=/bin/sleep 5" > ${DIR}/override.conf
systemctl daemon-reload
That should be roughly equivalent to what systemctl edit sddm
is doing.
edited Aug 5 at 13:09
Jeff Schaller
37.9k1053123
37.9k1053123
answered Aug 1 at 22:29
GracefulRestart
1,08427
1,08427
I've tried this solution, but I'm running into some problems. After adding this to my postinstall script, sddm still didn't start as expected. I logged in and noticed the/etc/systemd/system/sddm.service.d
directory did not exist. After creating this directory and running theecho
anddaemon-reload
myself, I rebooted and it still didn't work. Next I tried addingmkdir /etc/systemd/system/sddm.service.d
to the postinstall, and this directory still isn't being created! Regardless, doing it manually doesn't seem to work either.
– user5104897
Aug 2 at 17:41
When you usesystemctl edit sddm
, where does systemd put the override.conf? I am not sure why you would not be able to create the directory, check permissions or if selinux is stopping you.
– GracefulRestart
Aug 2 at 19:57
I'm able to create the directory and file manually, but they have no effect even afterdaemon-reload
- it's only when I usesystemctl edit sddm
that the changes actually take effect. Usingsystemctl
opens a buffer named/etc/systemd/system/sddm.service.d/.#override.conf52ea69f0b57f34f9
, but it does ultimately createsddm.service.d/override.conf
anyway.
– user5104897
Aug 2 at 20:45
add a comment |
I've tried this solution, but I'm running into some problems. After adding this to my postinstall script, sddm still didn't start as expected. I logged in and noticed the/etc/systemd/system/sddm.service.d
directory did not exist. After creating this directory and running theecho
anddaemon-reload
myself, I rebooted and it still didn't work. Next I tried addingmkdir /etc/systemd/system/sddm.service.d
to the postinstall, and this directory still isn't being created! Regardless, doing it manually doesn't seem to work either.
– user5104897
Aug 2 at 17:41
When you usesystemctl edit sddm
, where does systemd put the override.conf? I am not sure why you would not be able to create the directory, check permissions or if selinux is stopping you.
– GracefulRestart
Aug 2 at 19:57
I'm able to create the directory and file manually, but they have no effect even afterdaemon-reload
- it's only when I usesystemctl edit sddm
that the changes actually take effect. Usingsystemctl
opens a buffer named/etc/systemd/system/sddm.service.d/.#override.conf52ea69f0b57f34f9
, but it does ultimately createsddm.service.d/override.conf
anyway.
– user5104897
Aug 2 at 20:45
I've tried this solution, but I'm running into some problems. After adding this to my postinstall script, sddm still didn't start as expected. I logged in and noticed the
/etc/systemd/system/sddm.service.d
directory did not exist. After creating this directory and running the echo
and daemon-reload
myself, I rebooted and it still didn't work. Next I tried adding mkdir /etc/systemd/system/sddm.service.d
to the postinstall, and this directory still isn't being created! Regardless, doing it manually doesn't seem to work either.– user5104897
Aug 2 at 17:41
I've tried this solution, but I'm running into some problems. After adding this to my postinstall script, sddm still didn't start as expected. I logged in and noticed the
/etc/systemd/system/sddm.service.d
directory did not exist. After creating this directory and running the echo
and daemon-reload
myself, I rebooted and it still didn't work. Next I tried adding mkdir /etc/systemd/system/sddm.service.d
to the postinstall, and this directory still isn't being created! Regardless, doing it manually doesn't seem to work either.– user5104897
Aug 2 at 17:41
When you use
systemctl edit sddm
, where does systemd put the override.conf? I am not sure why you would not be able to create the directory, check permissions or if selinux is stopping you.– GracefulRestart
Aug 2 at 19:57
When you use
systemctl edit sddm
, where does systemd put the override.conf? I am not sure why you would not be able to create the directory, check permissions or if selinux is stopping you.– GracefulRestart
Aug 2 at 19:57
I'm able to create the directory and file manually, but they have no effect even after
daemon-reload
- it's only when I use systemctl edit sddm
that the changes actually take effect. Using systemctl
opens a buffer named /etc/systemd/system/sddm.service.d/.#override.conf52ea69f0b57f34f9
, but it does ultimately create sddm.service.d/override.conf
anyway.– user5104897
Aug 2 at 20:45
I'm able to create the directory and file manually, but they have no effect even after
daemon-reload
- it's only when I use systemctl edit sddm
that the changes actually take effect. Using systemctl
opens a buffer named /etc/systemd/system/sddm.service.d/.#override.conf52ea69f0b57f34f9
, but it does ultimately create sddm.service.d/override.conf
anyway.– user5104897
Aug 2 at 20:45
add a comment |
up vote
0
down vote
I want to second the answer given in 3 but I do it this way using tee
env SYSTEMD_EDITOR=tee sudo -E systemctl edit --system [your_unit_name] < [your_content_file]
When doing it this way you can feed the content via stdin rather than from a file, which can be useful when invoking systemctl from a script.
New contributor
add a comment |
up vote
0
down vote
I want to second the answer given in 3 but I do it this way using tee
env SYSTEMD_EDITOR=tee sudo -E systemctl edit --system [your_unit_name] < [your_content_file]
When doing it this way you can feed the content via stdin rather than from a file, which can be useful when invoking systemctl from a script.
New contributor
add a comment |
up vote
0
down vote
up vote
0
down vote
I want to second the answer given in 3 but I do it this way using tee
env SYSTEMD_EDITOR=tee sudo -E systemctl edit --system [your_unit_name] < [your_content_file]
When doing it this way you can feed the content via stdin rather than from a file, which can be useful when invoking systemctl from a script.
New contributor
I want to second the answer given in 3 but I do it this way using tee
env SYSTEMD_EDITOR=tee sudo -E systemctl edit --system [your_unit_name] < [your_content_file]
When doing it this way you can feed the content via stdin rather than from a file, which can be useful when invoking systemctl from a script.
New contributor
New contributor
answered 2 days ago
El Gow
1
1
New contributor
New contributor
add a comment |
add a comment |
up vote
-2
down vote
I'd attack the file directly:
sed -i 's/[Service]/ a
ExecStartPre=/bin/sleep 5' /usr/lib/systemd/system/sddm.service
1
editing files managed by a package is generally unreliable. An override would probably be a better option.
– smokes2345
Aug 1 at 22:36
This is incorrect. You shouldn't edit units from/usr/lib
directly, since the modifications are probably going to get clobbered next time the package is upgraded. Furthermore, what you suggest is likely to cause syntax errors, since the unit probably already has a[Service]
section and shouldn't really get another. Drop-ins are the correct way to deal with this kind of overrides. See the other answers for more details.
– Filipe Brandenburger
Aug 1 at 22:37
add a comment |
up vote
-2
down vote
I'd attack the file directly:
sed -i 's/[Service]/ a
ExecStartPre=/bin/sleep 5' /usr/lib/systemd/system/sddm.service
1
editing files managed by a package is generally unreliable. An override would probably be a better option.
– smokes2345
Aug 1 at 22:36
This is incorrect. You shouldn't edit units from/usr/lib
directly, since the modifications are probably going to get clobbered next time the package is upgraded. Furthermore, what you suggest is likely to cause syntax errors, since the unit probably already has a[Service]
section and shouldn't really get another. Drop-ins are the correct way to deal with this kind of overrides. See the other answers for more details.
– Filipe Brandenburger
Aug 1 at 22:37
add a comment |
up vote
-2
down vote
up vote
-2
down vote
I'd attack the file directly:
sed -i 's/[Service]/ a
ExecStartPre=/bin/sleep 5' /usr/lib/systemd/system/sddm.service
I'd attack the file directly:
sed -i 's/[Service]/ a
ExecStartPre=/bin/sleep 5' /usr/lib/systemd/system/sddm.service
answered Aug 1 at 22:02
dafydd
6402821
6402821
1
editing files managed by a package is generally unreliable. An override would probably be a better option.
– smokes2345
Aug 1 at 22:36
This is incorrect. You shouldn't edit units from/usr/lib
directly, since the modifications are probably going to get clobbered next time the package is upgraded. Furthermore, what you suggest is likely to cause syntax errors, since the unit probably already has a[Service]
section and shouldn't really get another. Drop-ins are the correct way to deal with this kind of overrides. See the other answers for more details.
– Filipe Brandenburger
Aug 1 at 22:37
add a comment |
1
editing files managed by a package is generally unreliable. An override would probably be a better option.
– smokes2345
Aug 1 at 22:36
This is incorrect. You shouldn't edit units from/usr/lib
directly, since the modifications are probably going to get clobbered next time the package is upgraded. Furthermore, what you suggest is likely to cause syntax errors, since the unit probably already has a[Service]
section and shouldn't really get another. Drop-ins are the correct way to deal with this kind of overrides. See the other answers for more details.
– Filipe Brandenburger
Aug 1 at 22:37
1
1
editing files managed by a package is generally unreliable. An override would probably be a better option.
– smokes2345
Aug 1 at 22:36
editing files managed by a package is generally unreliable. An override would probably be a better option.
– smokes2345
Aug 1 at 22:36
This is incorrect. You shouldn't edit units from
/usr/lib
directly, since the modifications are probably going to get clobbered next time the package is upgraded. Furthermore, what you suggest is likely to cause syntax errors, since the unit probably already has a [Service]
section and shouldn't really get another. Drop-ins are the correct way to deal with this kind of overrides. See the other answers for more details.– Filipe Brandenburger
Aug 1 at 22:37
This is incorrect. You shouldn't edit units from
/usr/lib
directly, since the modifications are probably going to get clobbered next time the package is upgraded. Furthermore, what you suggest is likely to cause syntax errors, since the unit probably already has a [Service]
section and shouldn't really get another. Drop-ins are the correct way to deal with this kind of overrides. See the other answers for more details.– Filipe Brandenburger
Aug 1 at 22:37
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.
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%2funix.stackexchange.com%2fquestions%2f459942%2fusing-systemctl-edit-via-bash-script%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