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

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

upgraded config files in /lib/systemd/system

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

Contents

  upgraded config files in /lib/systemd/system Harald Dunkel <harald.dunkel@aixigo.de> - 2017-02-28 14:20 +0100
    Re: upgraded config files in /lib/systemd/system Dominique Dumont <dod@debian.org> - 2017-02-28 15:50 +0100
      Re: upgraded config files in /lib/systemd/system Harald Dunkel <harri@afaics.de> - 2017-03-05 21:20 +0100
        Re: upgraded config files in /lib/systemd/system Michael Biebl <biebl@debian.org> - 2017-03-05 21:50 +0100
          Re: upgraded config files in /lib/systemd/system Michael Biebl <biebl@debian.org> - 2017-03-05 22:30 +0100
            Re: upgraded config files in /lib/systemd/system Sven Hartge <sven@svenhartge.de> - 2017-03-05 22:50 +0100
          Re: upgraded config files in /lib/systemd/system Harald Dunkel <harald.dunkel@aixigo.de> - 2017-03-09 13:00 +0100

#178262 — upgraded config files in /lib/systemd/system

Hi folks,

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?


Regards
Harri

[toc] | [next] | [standalone]

#178269

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

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

#178454

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/28/17 15:23, Dominique Dumont wrote:
> 
> I don't understand why a change in /lib/systemd/system should trigger a conflict warning.
> 

A unit file provided by the package maintainer might introduce new
dependencies, for example. Maybe an ExecStart or ExecStop script has
been changed, or there are new/different command line options.

I don't think that conflicts between the user's old modified unit
files in /etc and the new packages unit files are easy to avoid.


> 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.
> 

Sorry to say, but this doesn't solve anything. It just hides the
conflict. I understand that this hasn't been taken into account,
but it should be considered for Buster.


Regards
Harri

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEH2V614LbR/u1O+a1Cp4qnmbTgcsFAli8azMACgkQCp4qnmbT
gcvwagf+PU2QI2/0MPflk2JiN/Y+Y6jwH4KwhceqUQAZQi43zDJnB2C8a1HlJj+/
k/U/qoPNoBExqo2MW3OoaVg6Gr1SYs0fhs6kDge0vE/nZ+C8g+KCaDJNpkxlL8Yl
KgSViwuGCFWEnWJDGRs3zGgIFAD4EPIqlSN4Ap5wOuAZ6OSDakmBRtePZSdIc0G9
ea6mkhc68KhITi8aoe6FlTdjW+nqX2jezsMr0HyZfjZsPXztOpS+EIdhH27afudt
JxE1g9P36dDOHmTM75A1J5xCmJv/LwY00vvMzooaKhvy5vOrpmI5XOmWq51EyjwW
Blt4hqxXVivb8Y4DfEEvXSdwtfgZBQ==
=S+mQ
-----END PGP SIGNATURE-----

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

#178460

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

Am 05.03.2017 um 20:47 schrieb Harald Dunkel:
> On 02/28/17 15:23, Dominique Dumont wrote:
> 
>> I don't understand why a change in /lib/systemd/system should trigger a conflict warning.
> 
> 
> A unit file provided by the package maintainer might introduce new
> dependencies, for example. Maybe an ExecStart or ExecStop script has
> been changed, or there are new/different command line options.
> 
> I don't think that conflicts between the user's old modified unit
> files in /etc and the new packages unit files are easy to avoid.
> 

Keep in mind, that in most cases you don't need to override the package
provided service file completely by making a full copy of it in
/etc/systemd/system

You can extend/override individual bits via drop-in files (e.g. adding
additional dependencies/orderings). For a service foo.service you create

/etc/systemd/system/foo.service.d/bla.conf
The name is arbitrary, you just need to make sure it has a .conf extension.

Fwiw, systemctl edit (--full) foo.service can help you with that

https://www.freedesktop.org/software/systemd/man/systemctl.html#edit%20NAME%E2%80%A6

This is new in stretch, jessie's systemctl doesn't have that yet.

Regards,
Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

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

#178465

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

Am 05.03.2017 um 21:29 schrieb Michael Biebl:
> Fwiw, systemctl edit (--full) foo.service can help you with that
> 
> https://www.freedesktop.org/software/systemd/man/systemctl.html#edit%20NAME%E2%80%A6
> 
> This is new in stretch, jessie's systemctl doesn't have that yet.

Just to clarify here: The drop-in mechanism works in jessie as well,
what's missing is the "systemctl edit" functionality.

Useful in that regard is also systemd-delta, which will show you local
overrides or extensions.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

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

#178466

Michael Biebl <biebl@debian.org> wrote:

> Useful in that regard is also systemd-delta, which will show you local
> overrides or extensions.

Which still does not work for instanced units.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797839 and
https://github.com/systemd/systemd/issues/45

Grüße,
S°


-- 
Sigmentation fault. Core dumped.

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

#178608

On 03/05/17 21:29, Michael Biebl wrote:
> 
> Keep in mind, that in most cases you don't need to override the package
> provided service file completely by making a full copy of it in
> /etc/systemd/system
> 
> You can extend/override individual bits via drop-in files (e.g. adding
> additional dependencies/orderings). For a service foo.service you create
> 
> /etc/systemd/system/foo.service.d/bla.conf
> The name is arbitrary, you just need to make sure it has a .conf extension.
> 
> Fwiw, systemctl edit (--full) foo.service can help you with that
> 
> https://www.freedesktop.org/software/systemd/man/systemctl.html#edit%20NAME%E2%80%A6
> 

This is nice to have, but please remember that config options
accumulate for systemd.unit files. You still need /etc/systemd/\
system/foo.service to reliably override /lib/systemd/system/\
foo.service.

Since Debian already has a scheme to handle conflicts in
config files on an upgrade, I wonder why there is such a
high refusal to use it in this case?

If the config wasn't changed or if there are just some files in
/etc/systemd/system/foo.service.d, then this would be a noop.
But *if* there is a conflict, then the usual dialog should be
brought up, as for all other config files.

> This is new in stretch, jessie's systemctl doesn't have that yet.
> 

Focusing on Stretch or Buster is fine with me.


Regards
Harri

[toc] | [prev] | [standalone]

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

csiph-web