Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #178274 > unrolled thread

Re: upgraded config files in /lib/systemd/system

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: upgraded config files in /lib/systemd/system Marc Auslander <marcslists@gmail.com> - 2017-02-28 16:50 +0100
    Re: upgraded config files in /lib/systemd/system Sven Hartge <sven@svenhartge.de> - 2017-02-28 18:40 +0100
    Re: upgraded config files in /lib/systemd/system Jonathan Dowland <jmtd@debian.org> - 2017-03-06 15:50 +0100
      Re: upgraded config files in /lib/systemd/system Reco <recoverym4n@gmail.com> - 2017-03-06 17:10 +0100

#178274 — Re: upgraded config files in /lib/systemd/system

Dominique Dumont <dod@debian.org> writes:

> On Tuesday, 28 February 2017 14:01:18 CET Harald Dunkel wrote:
>> short question about /lib/systemd/system: AFAICS the config
>> files here are supposed to be overridden by local config files
>> in /etc/systemd/system, using the same path, as described in
>> systemd.unit(5)
>> 
>> How can I make sure that there is a conflict dialog at upgrade
>> time, if I have to modify the unit file shipped with my package?
>
> I don't understand why a change in /lib/systemd/system should trigger a 
> conflict warning.
>
> Either you have changed a value not modified by end user and there's no conflict
>
> Or you change a value overridden by user, then your change is not taken into 
> account by systemd: conflict is solved by giving priority to user value.
>
> Did I miss something ?
>
> All the best
> -- 
>  https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
> http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

IIRC in the "old" world, if you had a modified version of a config
file and an update modified the original released version, you got
a warning and a dialog which let you decide how to proceed.

The question is whether or not you will get such a warning using the
described method of modifying a config file by publishing a new
version in the override directory.

[toc] | [next] | [standalone]

#178278

Marc Auslander <marcslists@gmail.com> wrote:
> Dominique Dumont <dod@debian.org> writes:
>> On Tuesday, 28 February 2017 14:01:18 CET Harald Dunkel wrote:
>>> short question about /lib/systemd/system: AFAICS the config
>>> files here are supposed to be overridden by local config files
>>> in /etc/systemd/system, using the same path, as described in
>>> systemd.unit(5)
>>> 
>>> How can I make sure that there is a conflict dialog at upgrade
>>> time, if I have to modify the unit file shipped with my package?

>> I don't understand why a change in /lib/systemd/system should trigger a 
>> conflict warning.
>>
>> Either you have changed a value not modified by end user and there's no conflict

> IIRC in the "old" world, if you had a modified version of a config
> file and an update modified the original released version, you got a
> warning and a dialog which let you decide how to proceed.

> The question is whether or not you will get such a warning using the
> described method of modifying a config file by publishing a new
> version in the override directory.

If you copied the *whole* unit from /lib/systemd/system/foobar.service
to /etc/systemd/system/foobar.service, then you have been using the
override system the wrong way.

The correct (and documented) way is to

1) create /etc/systemd/system/foobar.service.d/
2) put your overrides and *only* your overrides into
   /etc/systemd/system/foobar.service.d/somename.conf

Or, starting with Stretch, you can just do "systemctl edit
foobar.service" and it will do the right thing for you.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#178493

[Multipart message — attachments visible in raw view] — view raw

On Tue, Feb 28, 2017 at 10:25:52AM -0500, Marc Auslander wrote:
> IIRC in the "old" world, if you had a modified version of a config
> file and an update modified the original released version, you got
> a warning and a dialog which let you decide how to proceed.

This is still the case on Debian systems: it's the "conffile" feature
of Debian packages.

Unfortunately systemd was designed in part around limitations of other
systems' package managers, such as RPM, which lack this feature. So
they invented the /etc/systemd/system-overrides-/lib/systemd/system
override scheme instead.

The techniques that others in this thread have mentioned for partially
overriding or supplanting an existing system file go some way to
redress this.

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [next] | [standalone]

#178497

	Hi.

On Mon, 6 Mar 2017 14:25:44 +0000
Jonathan Dowland <jmtd@debian.org> wrote:

> On Tue, Feb 28, 2017 at 10:25:52AM -0500, Marc Auslander wrote:
> > IIRC in the "old" world, if you had a modified version of a config
> > file and an update modified the original released version, you got
> > a warning and a dialog which let you decide how to proceed.
> 
> This is still the case on Debian systems: it's the "conffile" feature
> of Debian packages.
> 
> Unfortunately systemd was designed in part around limitations of other
> systems' package managers, such as RPM, which lack this feature. So
> they invented the /etc/systemd/system-overrides-/lib/systemd/system
> override scheme instead.

To be more precise, a file in RPM actually *can* be declared as a
configfile (rpm -qc). It's 'dialog' part aka debconf that's
deliberately missing there.
Since both RPM install and upgrade do not allow user input by
design, user-modified configfiles are preserved as is (usually),
rpm-provided configfiles are placed nearby with .rpmnew extension.

Reco

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web