Bug 756787 - RFE: allow overwrite options included with .include
Summary: RFE: allow overwrite options included with .include
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 874559 878088 891748 (view as bug list)
Depends On:
Blocks: systemd-RFE
TreeView+ depends on / blocked
 
Reported: 2011-11-24 14:37 UTC by Petr Lautrbach
Modified: 2021-10-11 15:22 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-26 02:44:28 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Petr Lautrbach 2011-11-24 14:37:36 UTC
Description of problem:

If I want to change only some directives in a default unit and I don't want to loose track of package updates, I should create new unit in /etc/systemd/system with .include of original unit. But This doesn't work if I need change option which can be specified more than once.

E.g. /etc/systemd/system/local-sshd.service
.include /lib/systemd/system/sshd.service
[Service]
Execstart=/usr/local/sbin/sshd -D $OPTIONS

will end with error message:

systemd[1]: sshd.service has more than one ExecStart setting, which is only allowed for Type=oneshot services. Refusing.

Ideas:
- introduce .include_overwrite
- allow reset option with empty value:
ExecStart=
Execstart=/usr/local/sbin/sshd -D $OPTIONS

Comment 1 Jóhann B. Guðmundsson 2011-11-24 15:18:40 UTC
I personally had though my self to file an RFE for an overwrite switch as in

.include
OverWrite=Yes
Exec$foo=bla 

But decided not to because once you start overwriting the default as opposed to be adding something to the unit you beat the purpose of .include and might just as well just copy the whole unit and edit it instead of adding several lines of codes trying to determine which one of multiple ExecStart/Pre/Post/ the end user is trying owerwrite.

Comment 2 Michal Schmidt 2011-11-24 16:07:47 UTC
> - allow reset option with empty value:
> ExecStart=
> Execstart=/usr/local/sbin/sshd -D $OPTIONS

I like this one because it was actually I who gave the idea to Petr :-)

Jóhann, I disagree with your objection. There's no need to determine anything. "ExecStart=" would simply mean "forget all ExecStart lines defined up to this point".

Comment 3 Michal Schmidt 2011-11-24 16:17:55 UTC
I would also find it nice to be able to remove selected values from lists.
For example, getty@.service has:

After=dev-%i.device systemd-user-sessions.service plymouth-quit-wait.service
After=rc-local.service

Wouldn't it be useful to be able to say:
.include /lib/systemd/system/getty@.service
[Unit]
After != rc-local.service

in order to remove one ordering dependency from the unit and preserve all the others? (I don't insist on the exact syntax)

Comment 4 Jóhann B. Guðmundsson 2011-11-24 16:32:35 UTC
If used in conjunction with After= Before wont you risk messing up ordering along with wants requires etc?


And in service section how are you going to solve which Exec$foo lines are going to be overwritten if there are more then one line?

Comment 5 Michal Schmidt 2011-11-24 17:08:06 UTC
(In reply to comment #4)
> If used in conjunction with After= Before wont you risk messing up ordering
> along with wants requires etc?

There's always a risk of messing things up when reconfiguring anything. You have to know what you're doing. I don't see why having the ability to remove selected dependencies would be particularly dangerous.

> And in service section how are you going to solve which Exec$foo lines are
> going to be overwritten if there are more then one line?

With the "ExecStart=" syntax? As I tried to explain in comment #2, all of them. Example:

ExecStart=foo
ExecStart=bar
ExecStart=
ExecStart=baz

The result would be the same as:
ExecStart=baz

Comment 6 Michal Schmidt 2012-11-19 16:16:24 UTC
*** Bug 878088 has been marked as a duplicate of this bug. ***

Comment 7 Michal Schmidt 2013-01-08 13:40:31 UTC
*** Bug 891748 has been marked as a duplicate of this bug. ***

Comment 8 Michal Schmidt 2013-01-15 12:21:57 UTC
*** Bug 874559 has been marked as a duplicate of this bug. ***

Comment 9 Lennart Poettering 2013-01-15 22:37:43 UTC
I like the ExecStart= syntax with an empty assignment. I think that's the way to go. I am sold.

Comment 10 James Withers 2013-01-16 08:16:54 UTC
Being able to override ExecStart is particularly useful for applications like MySQL or PostgreSQL; where config parameters can be passed on run. It allows for portable modifications that do not override core code and are not [at risk of being] lost in upgrades

Comment 11 Jóhann B. Guðmundsson 2013-01-16 10:29:58 UTC
Just ensure you wont wipe all Exec$foo= lines once this is implemented. 

Administrators might just want to replace one of those lines not all..

Comment 12 Lennart Poettering 2013-01-17 01:49:43 UTC
Implemented in git.

Comment 13 Fedora Update System 2013-01-28 19:13:18 UTC
systemd-197-1.fc18.2 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/systemd-197-1.fc18.2

Comment 14 Fedora Update System 2013-01-30 00:35:37 UTC
Package systemd-197-1.fc18.2:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-197-1.fc18.2'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-1590/systemd-197-1.fc18.2
then log in and leave karma (feedback).

Comment 15 Jóhann B. Guðmundsson 2013-01-30 07:16:34 UTC
Lennart how exactly did this get implemented?

Specifically what happens if I have for example two ExecStart lines and only want to replace one of them ( not all of them or everything there after )?

Comment 16 Michal Schmidt 2013-01-30 10:56:51 UTC
> Specifically what happens if I have for example two ExecStart lines and only
> want to replace one of them ( not all of them or everything there after )?

There's no way to do that. You'll have to clear them all and then re-add the ones you want.

ExecStart=
ExecStart=/usr/bin/foo
ExecStart=/usr/bin/bar

Comment 17 Jóhann B. Guðmundsson 2013-01-30 17:31:43 UTC
(In reply to comment #16)
> > Specifically what happens if I have for example two ExecStart lines and only
> > want to replace one of them ( not all of them or everything there after )?
> 
> There's no way to do that. You'll have to clear them all and then re-add the
> ones you want.
> 
> ExecStart=
> ExecStart=/usr/bin/foo
> ExecStart=/usr/bin/bar

That kinda defines this purpose does in it because you can just as well skip the .include line and copy the whole unit and edit it if comes down to that.

But I thought this could be achieving that by matching the exact line you want to 
replace ( search replace ) and just replace that one as in 

Or if you could define if many that it should only replace the first line with ExecStart and replace that or the second line containing ExecStart

Heck even saying replace line 5 in the unit with this line would be better then just blindly dismiss what ever comes after the line you want to replace

Comment 18 Michal Schmidt 2013-01-30 18:50:52 UTC
(In reply to comment #17)
> That kinda defines this purpose does in it because you can just as well skip
> the .include line and copy the whole unit and edit it if comes down to that.

Not quite. You can still inherit all other settings.

> But I thought this could be achieving that by matching the exact line you
> want to 
> replace ( search replace ) and just replace that one as in

You mean some sed-like capability? s/old/new/? 

> Or if you could define if many that it should only replace the first line
> with ExecStart and replace that or the second line containing ExecStart

I'm afraid this would be too fragile to use.

> Heck even saying replace line 5 in the unit with this line would be better
> then just blindly dismiss what ever comes after the line you want to replace

And this even more so.

Comment 19 Jóhann B. Guðmundsson 2013-01-30 18:59:57 UTC
(In reply to comment #18)
> (In reply to comment #17)
> > That kinda defines this purpose does in it because you can just as well skip
> > the .include line and copy the whole unit and edit it if comes down to that.
> 
> Not quite. You can still inherit all other settings.

Unless I'm misunderstanding something that will not happen in type oneshot units which often have more then one instance of the same ExecFoo line the same thing apply with other types that have multiple ExecStartPre/Post lines ( if you would replace either of those. 

> 
> > But I thought this could be achieving that by matching the exact line you
> > want to 
> > replace ( search replace ) and just replace that one as in
> 
> You mean some sed-like capability? s/old/new/? 

Yes 

Replace ExecStart=/bin/foo -a -b -c with ExecStart=/bin/foo -x- y -z which is the most common use case for this ( one line change ) the other is to add Restart=foo but I expect we will decide how we go forward with that @BRNO there are certain bits missing before we can default to that ( which leaves out only the one line changes )

Comment 20 Fedora Update System 2013-02-23 01:02:40 UTC
Package initscripts-9.42.2-1.fc18, systemd-197-1.fc18.2:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing initscripts-9.42.2-1.fc18 systemd-197-1.fc18.2'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-1590/initscripts-9.42.2-1.fc18,systemd-197-1.fc18.2
then log in and leave karma (feedback).

Comment 21 Fedora Update System 2013-02-26 02:44:32 UTC
initscripts-9.42.2-1.fc18, systemd-197-1.fc18.2 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.