Discussion:
sysv-generator: doesn't handle /etc/insserv/overrides or /etc/chkconfig.d
(too old to reply)
Christian Seiler
2015-02-15 16:21:34 UTC
Permalink
Hi,

I just noticed that sysv-generator doesn't handle
/etc/insserv/overrides (e.g. older SuSE, Debian) or /etc/chkconfig.d
(e.g. RHEL <= 6, Centos, old Fedora), it just ignores it, thus not
retaining administrator overrides to init script headers. Now
obviously, one can create a native unit file that overrides the sysv
service, but that is not always so nice.

In the simplest case, the init script is trivial and you just create a
simple native service and are better off anyway. But most of the time,
init scripts where you want to override headers are provided by third
parties, and do a lot of involved things, and as an administrator you
don't want to port the old init script yourself, you just want to call
the original one and be done with it. (And even worse, some
third-party init scripts don't even come with LSB headers, even in
2015.)

Obviously, one can always just copy and modify the generated service
file from /run/systemd/generator.late, so it's not like there is no
technical solution to this issue, but I think this is one the ugliest
ways for the administrator to achieve this, because the settings you
want to override are in one format (LSB headers), the format you have
to use to override them is a completely different one (service file).
Also, if you want to compare the two, you have to manually keep a
copy of the service file around as a reference, since sysv-generator
doesn't generate units where there's a native one around (which is
good in general, but hurts here), otherwise you can't easily just
look at both files and view the changes.

Would you accept a patch that makes the sysv-generator consider these
local overrides? (I have a test patch just for insserv/overrides
that's diffstat +14 -8; for chkconfig.d it would be a bit more longer,
because you can override individual settings there (and not just all
of them at once), but shouldn't be too complicated.

Christian
Lennart Poettering
2015-02-16 10:42:50 UTC
Permalink
Post by Christian Seiler
Hi,
I just noticed that sysv-generator doesn't handle
/etc/insserv/overrides (e.g. older SuSE, Debian) or /etc/chkconfig.d
(e.g. RHEL <= 6, Centos, old Fedora), it just ignores it, thus not
retaining administrator overrides to init script headers. Now
obviously, one can create a native unit file that overrides the sysv
service, but that is not always so nice.
In the simplest case, the init script is trivial and you just create a
simple native service and are better off anyway. But most of the time,
init scripts where you want to override headers are provided by third
parties, and do a lot of involved things, and as an administrator you
don't want to port the old init script yourself, you just want to call
the original one and be done with it. (And even worse, some
third-party init scripts don't even come with LSB headers, even in
2015.)
Obviously, one can always just copy and modify the generated service
file from /run/systemd/generator.late, so it's not like there is no
technical solution to this issue, but I think this is one the ugliest
ways for the administrator to achieve this, because the settings you
want to override are in one format (LSB headers), the format you have
to use to override them is a completely different one (service file).
Also, if you want to compare the two, you have to manually keep a
copy of the service file around as a reference, since sysv-generator
doesn't generate units where there's a native one around (which is
good in general, but hurts here), otherwise you can't easily just
look at both files and view the changes.
Would you accept a patch that makes the sysv-generator consider these
local overrides? (I have a test patch just for insserv/overrides
that's diffstat +14 -8; for chkconfig.d it would be a bit more longer,
because you can override individual settings there (and not just all
of them at once), but shouldn't be too complicated.
We currently have support for calling out to chkconfig, but zero
support for calling out to update-rcd or insserv. It would be weird
supporting some facilities they provide without supporting the tools
themsevles...

This is also the first time I hear about chkconfig.d, which is kinda
interesting, given that the transition on Fedora is already years
past... We never got any request for it to be supported
explicitly. Which makes me wonder if it really makes sense to support
this now.

So, I am pretty conservative about this. That said I am note entirely
sure what precisely the patch you propose would entail. What precisely
would it do? Just look for init scripts in some other place in
addition to /etc/rc.d?

Lennart
--
Lennart Poettering, Red Hat
Christian Seiler
2015-02-16 11:25:10 UTC
Permalink
Hi,
Post by Lennart Poettering
Post by Christian Seiler
Would you accept a patch that makes the sysv-generator consider these
local overrides? (I have a test patch just for insserv/overrides
that's diffstat +14 -8; for chkconfig.d it would be a bit more longer,
because you can override individual settings there (and not just all
of them at once), but shouldn't be too complicated.
We currently have support for calling out to chkconfig, but zero
support for calling out to update-rcd or insserv. It would be weird
supporting some facilities they provide without supporting the tools
themsevles...
This is also the first time I hear about chkconfig.d, which is kinda
interesting, given that the transition on Fedora is already years
past... We never got any request for it to be supported
explicitly. Which makes me wonder if it really makes sense to support
this now.
So, I am pretty conservative about this. That said I am note entirely
sure what precisely the patch you propose would entail. What precisely
would it do? Just look for init scripts in some other place in
addition to /etc/rc.d?
So this would definitely NOT call out to anything at all, this is just
about the possibility to override headers (LSB or chkconfig ones) in
init scripts.

Basically, you have the following semantics

- insserv (SuSE/Debian), when it processes /etc/init.d/$NAME, it also
looks for /etc/insserv/overrides/$NAME. If the latter exists, it
reads the LSB headers (but ONLY the LSB headers) from that file and
completely ignores the LSB headers in /etc/init.d/$NAME (i.e. that
file is not parsed at all). But the script called is still the
original /etc/init.d/$NAME.

- chkconfig (Fedora, RHEL, ...), when it processes /etc/init.d/$NAME,
it also looks for /etc/chkconfig.d/$NAME. If the latter exists,
every header set in that file overrides the corresponding header in
the original init script (but the original init script is still
read).

You couldn't override init scripts that way - if you wanted to do that,
you'd have to replace them completely. But if you just want to alter
(or even specify for the first time for certain third-party scripts)
dependency information but keep getting updates for the init script
from the software vendor, this was really, really useful.

A patch that would incorporate both would be something along the lines
of:

- add sysv_override_path to LookupPaths and sysv_override_type
override_type would be either SYSV_OVERRIDE_UPDATING (chkconfig.d
semantics) or SYSV_OVERRIDE_REPLACING (insserv semantics)

- add override_path to struct SysvStub and fill it in
enumerate_sysv() with
lp->sysv_override_path + "/" + scriptname

- load_sysv(SysvStub *s) -> load_sysv(SysvStub *s, const char *path)
+ use that path instead of s->path in there

- in main, replace q = load_sysv(service) with something like
if (!file_exists(service->override_path) || lp->sysv_override_type == SYSV_OVERRIDE_UPDATING) {
q = load_sysv(service, service->path);
if (q < 0)
continue;
}
if (file_exists(service->override_path)) {
q = load_sysv(service, service->override_path);
if (q < 0)
continue;
}

- continue to use s->path for ExecStart etc.

I don't think that would be terribly complicated, but I haven't written
and tested it yet, since I first wanted to know whether you'd consider
this at all.

Note that on servers running Debian I've used /etc/insserv/overrides
countless times over the past years, so maybe chkconfig.d wasn't
something that was widely popularized, but insserv/overrides definitely
was.

Christian
Lennart Poettering
2015-02-16 12:59:44 UTC
Permalink
Post by Christian Seiler
Hi,
Post by Lennart Poettering
Post by Christian Seiler
Would you accept a patch that makes the sysv-generator consider these
local overrides? (I have a test patch just for insserv/overrides
that's diffstat +14 -8; for chkconfig.d it would be a bit more longer,
because you can override individual settings there (and not just all
of them at once), but shouldn't be too complicated.
We currently have support for calling out to chkconfig, but zero
support for calling out to update-rcd or insserv. It would be weird
supporting some facilities they provide without supporting the tools
themsevles...
This is also the first time I hear about chkconfig.d, which is kinda
interesting, given that the transition on Fedora is already years
past... We never got any request for it to be supported
explicitly. Which makes me wonder if it really makes sense to support
this now.
So, I am pretty conservative about this. That said I am note entirely
sure what precisely the patch you propose would entail. What precisely
would it do? Just look for init scripts in some other place in
addition to /etc/rc.d?
So this would definitely NOT call out to anything at all, this is just
about the possibility to override headers (LSB or chkconfig ones) in
init scripts.
Basically, you have the following semantics
- insserv (SuSE/Debian), when it processes /etc/init.d/$NAME, it also
looks for /etc/insserv/overrides/$NAME. If the latter exists, it
reads the LSB headers (but ONLY the LSB headers) from that file and
completely ignores the LSB headers in /etc/init.d/$NAME (i.e. that
file is not parsed at all). But the script called is still the
original /etc/init.d/$NAME.
- chkconfig (Fedora, RHEL, ...), when it processes /etc/init.d/$NAME,
it also looks for /etc/chkconfig.d/$NAME. If the latter exists,
every header set in that file overrides the corresponding header in
the original init script (but the original init script is still
read).
Well, if this is really just about overriding the LSB headers, and
nobody so far ever asked for this functionality, wouldn't it be a
better and easier way out to just recommend people to do systemd-style
drop-ins? I mean, those also work on units generated by the sysv
generator...
Post by Christian Seiler
You couldn't override init scripts that way - if you wanted to do that,
you'd have to replace them completely. But if you just want to alter
(or even specify for the first time for certain third-party scripts)
dependency information but keep getting updates for the init script
from the software vendor, this was really, really useful.
Since I never heard anyone asking for this, I doubt it was really that
useful in real life...
Post by Christian Seiler
Note that on servers running Debian I've used /etc/insserv/overrides
countless times over the past years, so maybe chkconfig.d wasn't
something that was widely popularized, but insserv/overrides definitely
was.
Again given that on DEbian we don't even have hookup to
insserv/update-rcd, I kinda wonder if it would be appropriate to
support this facet of it, without supporting the actual core bit.

I also believ that "systemctl edit" is a much nicer interface for all
of this, and it works on both sysv scripts and unit files...

Lennart
--
Lennart Poettering, Red Hat
Michael Biebl
2015-02-16 13:13:42 UTC
Permalink
Post by Lennart Poettering
Well, if this is really just about overriding the LSB headers, and
nobody so far ever asked for this functionality, wouldn't it be a
better and easier way out to just recommend people to do systemd-style
drop-ins? I mean, those also work on units generated by the sysv
generator...
Not quite. While you can use drop-in snippets to amend
orderings/depends, it's (unfortunately) not possible to override
Wants=,Before= etc.
With insserv overrides you can apparently *replace* the LSB header of
an SysV init script.
Post by Lennart Poettering
Post by Christian Seiler
You couldn't override init scripts that way - if you wanted to do that,
you'd have to replace them completely. But if you just want to alter
(or even specify for the first time for certain third-party scripts)
dependency information but keep getting updates for the init script
from the software vendor, this was really, really useful.
Since I never heard anyone asking for this, I doubt it was really that
useful in real life...
To be fair, there is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759001


We never raised that upstream though.
Post by Lennart Poettering
Post by Christian Seiler
Note that on servers running Debian I've used /etc/insserv/overrides
countless times over the past years, so maybe chkconfig.d wasn't
something that was widely popularized, but insserv/overrides definitely
was.
Again given that on DEbian we don't even have hookup to
insserv/update-rcd, I kinda wonder if it would be appropriate to
support this facet of it, without supporting the actual core bit.
I also believ that "systemctl edit" is a much nicer interface for all
of this, and it works on both sysv scripts and unit files...
Agreed, systemctl edit is much nicer. Unfortunately, as said above,
drop-ins can *not* be used to override all aspects of a native unit
file. So it's not (yet) a complete replacement for insserv overrides.


If it would be possible to unset Wants= or After=, just like other
service properties, then things would be different.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Lennart Poettering
2015-02-16 13:16:21 UTC
Permalink
Post by Michael Biebl
Post by Lennart Poettering
Well, if this is really just about overriding the LSB headers, and
nobody so far ever asked for this functionality, wouldn't it be a
better and easier way out to just recommend people to do systemd-style
drop-ins? I mean, those also work on units generated by the sysv
generator...
Not quite. While you can use drop-in snippets to amend
orderings/depends, it's (unfortunately) not possible to override
Wants=,Before= etc.
There have been discussions to allow masking deps via /dev/null
symlinks in .wants/ and .requires/ dirs... I think that'd be a better
solution...
Post by Michael Biebl
Post by Lennart Poettering
Since I never heard anyone asking for this, I doubt it was really that
useful in real life...
To be fair, there is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759001
We never raised that upstream though.
On Fedora I am not aware of any request to support this over all those
years!
Post by Michael Biebl
Post by Lennart Poettering
Post by Christian Seiler
Note that on servers running Debian I've used /etc/insserv/overrides
countless times over the past years, so maybe chkconfig.d wasn't
something that was widely popularized, but insserv/overrides definitely
was.
Again given that on DEbian we don't even have hookup to
insserv/update-rcd, I kinda wonder if it would be appropriate to
support this facet of it, without supporting the actual core bit.
I also believ that "systemctl edit" is a much nicer interface for all
of this, and it works on both sysv scripts and unit files...
Agreed, systemctl edit is much nicer. Unfortunately, as said above,
drop-ins can *not* be used to override all aspects of a native unit
file. So it's not (yet) a complete replacement for insserv overrides.
If it would be possible to unset Wants= or After=, just like other
service properties, then things would be different.
As mentioned, I'd be happy to take patches to make precisely that work!

Lennart
--
Lennart Poettering, Red Hat
Christian Seiler
2015-02-16 15:19:47 UTC
Permalink
Post by Lennart Poettering
Post by Michael Biebl
Not quite. While you can use drop-in snippets to amend
orderings/depends, it's (unfortunately) not possible to override
Wants=,Before= etc.
There have been discussions to allow masking deps via /dev/null
symlinks in .wants/ and .requires/ dirs... I think that'd be a better
solution...
[...]
Post by Michael Biebl
Agreed, systemctl edit is much nicer. Unfortunately, as said above,
drop-ins can *not* be used to override all aspects of a native unit
file. So it's not (yet) a complete replacement for insserv
overrides.
If it would be possible to unset Wants= or After=, just like other
service properties, then things would be different.
As mentioned, I'd be happy to take patches to make precisely that work!
Last time I talked about this here, there was a lot of confusion, so
I didn't pursue it further. But I would really like to get this to
work, but before I start with a patch, I'd like to explain what I'd
like to do before working on it, to see if it works for you.

The semantics I'd like to see would be the following:

- anything in /etc named exactly the same as in /usr/lib overrides
the latter, just as is already the case with units and drop-ins

=> allow masking of .wants/ and .requires/ with symlinks to
/dev/null (I think you were in favor of that)

- additionally, postpone processing of dependencies in unit files
until the entire unit (and all drop-ins) have been read in

For example, even without a drop-in:

a.service:
[Unit]
Wants=b.service
Wants=
Wants=c.service

After that, Wants should be set to c.service. Note that this
should NOT affect dependencies set in other ways, i.e. via
.wants/ directories or by dependencies of other services, this
should JUST alter what was specified in the unit itself.

A more complex example to illustrate the latter:

/usr/lib/.../a.service:
[Unit]
Wants=b.service
After=c.service

/usr/lib/.../a.service.wants/d.service -> /usr/lib/.../d.service
/usr/lib/.../a.service.wants/e.service -> /usr/lib/.../e.service

/usr/lib/.../f.service
[Unit]
Before=a.service

/etc/.../a.service.d/dont-depend-on-b.conf:
[Unit]
Wants=

/etc/.../a.service.d/not-after-c.conf:
[Unit]
After=

/etc/.../a.service.wants/e.service -> /dev/null

In the end, the dependnecies should be:

Wants=d.service
- b.service gets removed via drop-in
- e.service gets removed because it's masked
- but d.service stays, because it was never defined in
the unit file, so a drop-in doesn't override it, only
the mask does

After=f.service
- c.service gets removed via drop-in
- f.service is not declared in the original unit file but
rather in f.service as a Before= dependency, so you'd
have to override that to make this go into effect

The general principle would be: you can drop stuff at the same
place it's defined. If it's defined as After= in a unit,
override it in a drop-in for that unit, if it's defined as
Before= in another unit, override it in a drop-in for the other
unit, and if it's defined in the filesystem via .wants/ or
.requires/, you can override it by masking it in the filesystem.
Only in the end will all remaining dependencies be combined to
make up the entire list of dependencies for that service.

Would you be agreeable to these semantics? If so, I'll hack up a
patch.

Christian
Zbigniew Jędrzejewski-Szmek
2015-04-17 16:47:58 UTC
Permalink
Post by Christian Seiler
Post by Lennart Poettering
Post by Michael Biebl
Not quite. While you can use drop-in snippets to amend
orderings/depends, it's (unfortunately) not possible to override
Wants=,Before= etc.
There have been discussions to allow masking deps via /dev/null
symlinks in .wants/ and .requires/ dirs... I think that'd be a better
solution...
[...]
Post by Michael Biebl
Agreed, systemctl edit is much nicer. Unfortunately, as said above,
drop-ins can *not* be used to override all aspects of a native unit
file. So it's not (yet) a complete replacement for insserv
overrides.
If it would be possible to unset Wants= or After=, just like other
service properties, then things would be different.
As mentioned, I'd be happy to take patches to make precisely that work!
Last time I talked about this here, there was a lot of confusion, so
I didn't pursue it further. But I would really like to get this to
work, but before I start with a patch, I'd like to explain what I'd
like to do before working on it, to see if it works for you.
- anything in /etc named exactly the same as in /usr/lib overrides
the latter, just as is already the case with units and drop-ins
=> allow masking of .wants/ and .requires/ with symlinks to
/dev/null (I think you were in favor of that)
- additionally, postpone processing of dependencies in unit files
until the entire unit (and all drop-ins) have been read in
[Unit]
Wants=b.service
Wants=
Wants=c.service
After that, Wants should be set to c.service. Note that this
should NOT affect dependencies set in other ways, i.e. via
.wants/ directories or by dependencies of other services, this
should JUST alter what was specified in the unit itself.
[Unit]
Wants=b.service
After=c.service
/usr/lib/.../a.service.wants/d.service -> /usr/lib/.../d.service
/usr/lib/.../a.service.wants/e.service -> /usr/lib/.../e.service
/usr/lib/.../f.service
[Unit]
Before=a.service
[Unit]
Wants=
[Unit]
After=
/etc/.../a.service.wants/e.service -> /dev/null
Wants=d.service
- b.service gets removed via drop-in
- e.service gets removed because it's masked
- but d.service stays, because it was never defined in
the unit file, so a drop-in doesn't override it, only
the mask does
After=f.service
- c.service gets removed via drop-in
- f.service is not declared in the original unit file but
rather in f.service as a Before= dependency, so you'd
have to override that to make this go into effect
The general principle would be: you can drop stuff at the same
place it's defined. If it's defined as After= in a unit,
override it in a drop-in for that unit, if it's defined as
Before= in another unit, override it in a drop-in for the other
unit, and if it's defined in the filesystem via .wants/ or
.requires/, you can override it by masking it in the filesystem.
Only in the end will all remaining dependencies be combined to
make up the entire list of dependencies for that service.
Would you be agreeable to these semantics? If so, I'll hack up a
patch.
Seems quite intuitive to me. Would be great to have this implemented.

Zbyszek
Andrei Borzenkov
2015-04-19 06:29:55 UTC
Permalink
В Fri, 17 Apr 2015 16:47:58 +0000
Post by Zbigniew Jędrzejewski-Szmek
Post by Christian Seiler
Post by Lennart Poettering
Post by Michael Biebl
Not quite. While you can use drop-in snippets to amend
orderings/depends, it's (unfortunately) not possible to override
Wants=,Before= etc.
There have been discussions to allow masking deps via /dev/null
symlinks in .wants/ and .requires/ dirs... I think that'd be a better
solution...
[...]
Post by Michael Biebl
Agreed, systemctl edit is much nicer. Unfortunately, as said above,
drop-ins can *not* be used to override all aspects of a native unit
file. So it's not (yet) a complete replacement for insserv
overrides.
If it would be possible to unset Wants= or After=, just like other
service properties, then things would be different.
As mentioned, I'd be happy to take patches to make precisely that work!
Last time I talked about this here, there was a lot of confusion, so
I didn't pursue it further. But I would really like to get this to
work, but before I start with a patch, I'd like to explain what I'd
like to do before working on it, to see if it works for you.
- anything in /etc named exactly the same as in /usr/lib overrides
the latter, just as is already the case with units and drop-ins
=> allow masking of .wants/ and .requires/ with symlinks to
/dev/null (I think you were in favor of that)
- additionally, postpone processing of dependencies in unit files
until the entire unit (and all drop-ins) have been read in
[Unit]
Wants=b.service
Wants=
Wants=c.service
After that, Wants should be set to c.service. Note that this
should NOT affect dependencies set in other ways, i.e. via
.wants/ directories or by dependencies of other services, this
should JUST alter what was specified in the unit itself.
[Unit]
Wants=b.service
After=c.service
/usr/lib/.../a.service.wants/d.service -> /usr/lib/.../d.service
/usr/lib/.../a.service.wants/e.service -> /usr/lib/.../e.service
/usr/lib/.../f.service
[Unit]
Before=a.service
[Unit]
Wants=
[Unit]
After=
/etc/.../a.service.wants/e.service -> /dev/null
Wants=d.service
- b.service gets removed via drop-in
- e.service gets removed because it's masked
- but d.service stays, because it was never defined in
the unit file, so a drop-in doesn't override it, only
the mask does
After=f.service
- c.service gets removed via drop-in
- f.service is not declared in the original unit file but
rather in f.service as a Before= dependency, so you'd
have to override that to make this go into effect
The general principle would be: you can drop stuff at the same
place it's defined. If it's defined as After= in a unit,
override it in a drop-in for that unit, if it's defined as
Before= in another unit, override it in a drop-in for the other
unit, and if it's defined in the filesystem via .wants/ or
.requires/, you can override it by masking it in the filesystem.
Only in the end will all remaining dependencies be combined to
make up the entire list of dependencies for that service.
Would you be agreeable to these semantics? If so, I'll hack up a
patch.
Seems quite intuitive to me. Would be great to have this implemented.
Unless I'm mistaken, the only real change is that Wants= will clear
list, just like it does it for ExecStart=. This should be rather
straightforward to implement I guess.
Zbigniew Jędrzejewski-Szmek
2015-04-19 13:19:37 UTC
Permalink
Post by Andrei Borzenkov
В Fri, 17 Apr 2015 16:47:58 +0000
Post by Zbigniew Jędrzejewski-Szmek
Post by Christian Seiler
Post by Lennart Poettering
Post by Michael Biebl
Not quite. While you can use drop-in snippets to amend
orderings/depends, it's (unfortunately) not possible to override
Wants=,Before= etc.
There have been discussions to allow masking deps via /dev/null
symlinks in .wants/ and .requires/ dirs... I think that'd be a better
solution...
[...]
Post by Michael Biebl
Agreed, systemctl edit is much nicer. Unfortunately, as said above,
drop-ins can *not* be used to override all aspects of a native unit
file. So it's not (yet) a complete replacement for insserv overrides.
If it would be possible to unset Wants= or After=, just like other
service properties, then things would be different.
As mentioned, I'd be happy to take patches to make precisely that work!
Last time I talked about this here, there was a lot of confusion, so
I didn't pursue it further. But I would really like to get this to
work, but before I start with a patch, I'd like to explain what I'd
like to do before working on it, to see if it works for you.
- anything in /etc named exactly the same as in /usr/lib overrides
the latter, just as is already the case with units and drop-ins
=> allow masking of .wants/ and .requires/ with symlinks to
/dev/null (I think you were in favor of that)
- additionally, postpone processing of dependencies in unit files
until the entire unit (and all drop-ins) have been read in
[Unit]
Wants=b.service
Wants=
Wants=c.service
After that, Wants should be set to c.service. Note that this
should NOT affect dependencies set in other ways, i.e. via
.wants/ directories or by dependencies of other services, this
should JUST alter what was specified in the unit itself.
[Unit]
Wants=b.service
After=c.service
/usr/lib/.../a.service.wants/d.service -> /usr/lib/.../d.service
/usr/lib/.../a.service.wants/e.service -> /usr/lib/.../e.service
/usr/lib/.../f.service
[Unit]
Before=a.service
[Unit]
Wants=
[Unit]
After=
/etc/.../a.service.wants/e.service -> /dev/null
Wants=d.service
- b.service gets removed via drop-in
- e.service gets removed because it's masked
- but d.service stays, because it was never defined in
the unit file, so a drop-in doesn't override it, only
the mask does
After=f.service
- c.service gets removed via drop-in
- f.service is not declared in the original unit file but
rather in f.service as a Before= dependency, so you'd
have to override that to make this go into effect
The general principle would be: you can drop stuff at the same
place it's defined. If it's defined as After= in a unit,
override it in a drop-in for that unit, if it's defined as
Before= in another unit, override it in a drop-in for the other
unit, and if it's defined in the filesystem via .wants/ or
.requires/, you can override it by masking it in the filesystem.
Only in the end will all remaining dependencies be combined to
make up the entire list of dependencies for that service.
Would you be agreeable to these semantics? If so, I'll hack up a
patch.
Seems quite intuitive to me. Would be great to have this implemented.
Unless I'm mistaken, the only real change is that Wants= will clear
list, just like it does it for ExecStart=. This should be rather
straightforward to implement I guess.
Also links in .wants and .requires can be masked. It's not a huge change,
but I not trivial either -- and this part of the code is notriously had to
get right.

Zbyszek
Andrei Borzenkov
2015-04-19 14:08:04 UTC
Permalink
В Sun, 19 Apr 2015 13:19:37 +0000
Post by Zbigniew Jędrzejewski-Szmek
Post by Andrei Borzenkov
В Fri, 17 Apr 2015 16:47:58 +0000
Post by Zbigniew Jędrzejewski-Szmek
Post by Christian Seiler
Post by Lennart Poettering
Post by Michael Biebl
Not quite. While you can use drop-in snippets to amend
orderings/depends, it's (unfortunately) not possible to override
Wants=,Before= etc.
There have been discussions to allow masking deps via /dev/null
symlinks in .wants/ and .requires/ dirs... I think that'd be a better
solution...
[...]
Post by Michael Biebl
Agreed, systemctl edit is much nicer. Unfortunately, as said above,
drop-ins can *not* be used to override all aspects of a native unit
file. So it's not (yet) a complete replacement for insserv overrides.
If it would be possible to unset Wants= or After=, just like other
service properties, then things would be different.
As mentioned, I'd be happy to take patches to make precisely that work!
Last time I talked about this here, there was a lot of confusion, so
I didn't pursue it further. But I would really like to get this to
work, but before I start with a patch, I'd like to explain what I'd
like to do before working on it, to see if it works for you.
- anything in /etc named exactly the same as in /usr/lib overrides
the latter, just as is already the case with units and drop-ins
=> allow masking of .wants/ and .requires/ with symlinks to
/dev/null (I think you were in favor of that)
- additionally, postpone processing of dependencies in unit files
until the entire unit (and all drop-ins) have been read in
[Unit]
Wants=b.service
Wants=
Wants=c.service
After that, Wants should be set to c.service. Note that this
should NOT affect dependencies set in other ways, i.e. via
.wants/ directories or by dependencies of other services, this
should JUST alter what was specified in the unit itself.
[Unit]
Wants=b.service
After=c.service
/usr/lib/.../a.service.wants/d.service -> /usr/lib/.../d.service
/usr/lib/.../a.service.wants/e.service -> /usr/lib/.../e.service
/usr/lib/.../f.service
[Unit]
Before=a.service
[Unit]
Wants=
[Unit]
After=
/etc/.../a.service.wants/e.service -> /dev/null
Wants=d.service
- b.service gets removed via drop-in
- e.service gets removed because it's masked
- but d.service stays, because it was never defined in
the unit file, so a drop-in doesn't override it, only
the mask does
After=f.service
- c.service gets removed via drop-in
- f.service is not declared in the original unit file but
rather in f.service as a Before= dependency, so you'd
have to override that to make this go into effect
The general principle would be: you can drop stuff at the same
place it's defined. If it's defined as After= in a unit,
override it in a drop-in for that unit, if it's defined as
Before= in another unit, override it in a drop-in for the other
unit, and if it's defined in the filesystem via .wants/ or
.requires/, you can override it by masking it in the filesystem.
Only in the end will all remaining dependencies be combined to
make up the entire list of dependencies for that service.
Would you be agreeable to these semantics? If so, I'll hack up a
patch.
Seems quite intuitive to me. Would be great to have this implemented.
Unless I'm mistaken, the only real change is that Wants= will clear
list, just like it does it for ExecStart=. This should be rather
straightforward to implement I guess.
Also links in .wants and .requires can be masked. It's not a huge change,
but I not trivial either -- and this part of the code is notriously had to
get right.
What about Wants-=e.service in dropin? Dropins are processed
after .{wants,requires}.d and has advantage that you can remove also
static dependency from unit definition file, not only mask another
directory.
Lennart Poettering
2015-04-23 18:41:07 UTC
Permalink
Post by Andrei Borzenkov
What about Wants-=e.service in dropin? Dropins are processed
after .{wants,requires}.d and has advantage that you can remove also
static dependency from unit definition file, not only mask another
directory.
This has been requested before, but I'd be very careful with this. I
really don't want to turn this into a complex language really, and
especially not in one that knows different kinds of assignments. I
mean, already we aren't simple .ini files anymore, since we allow
assigning the empty string for resets, and allow multiple assignments
that add things up. But I'd *really* like to avoid deviating even
further from the simplicity that ini files are.

Or let's say it like this: I am very keen on keeping the file
structure as simple as "just a list of key-value pairs", possibly with
[sections] and comments, and that's it.

Lennart
--
Lennart Poettering, Red Hat
Lennart Poettering
2015-04-23 18:38:14 UTC
Permalink
Post by Andrei Borzenkov
Unless I'm mistaken, the only real change is that Wants= will clear
list, just like it does it for ExecStart=. This should be rather
straightforward to implement I guess.
Actually it's not that easy. You need to collect the deps created from
unit configuration into a set of hashmaps of their own, and then add a final
"commit" step that merges those into the real deps. And if we want to
do this without needless copies and allocations this is actually not
easy at all.

Lennart
--
Lennart Poettering, Red Hat
Christian Seiler
2015-04-23 18:54:56 UTC
Permalink
Post by Lennart Poettering
Post by Andrei Borzenkov
Unless I'm mistaken, the only real change is that Wants= will clear
list, just like it does it for ExecStart=. This should be rather
straightforward to implement I guess.
Actually it's not that easy. You need to collect the deps created from
unit configuration into a set of hashmaps of their own, and then add a final
"commit" step that merges those into the real deps. And if we want to
do this without needless copies and allocations this is actually not
easy at all.
Yes, I know, because I'm currently working on a patch for this. ;-)

I'll probably send a first version in a couple of days.

Christian
Lennart Poettering
2015-04-23 18:36:14 UTC
Permalink
Post by Christian Seiler
Last time I talked about this here, there was a lot of confusion, so
I didn't pursue it further. But I would really like to get this to
work, but before I start with a patch, I'd like to explain what I'd
like to do before working on it, to see if it works for you.
- anything in /etc named exactly the same as in /usr/lib overrides
the latter, just as is already the case with units and drop-ins
=> allow masking of .wants/ and .requires/ with symlinks to
/dev/null (I think you were in favor of that)
Sounds good. I like. +1. Me gusta.
Post by Christian Seiler
- additionally, postpone processing of dependencies in unit files
until the entire unit (and all drop-ins) have been read in
[Unit]
Wants=b.service
Wants=
Wants=c.service
After that, Wants should be set to c.service. Note that this
should NOT affect dependencies set in other ways, i.e. via
.wants/ directories or by dependencies of other services, this
should JUST alter what was specified in the unit itself.
I figure I can agree with this, too.
Post by Christian Seiler
The general principle would be: you can drop stuff at the same
place it's defined. If it's defined as After= in a unit,
override it in a drop-in for that unit, if it's defined as
Before= in another unit, override it in a drop-in for the other
unit, and if it's defined in the filesystem via .wants/ or
.requires/, you can override it by masking it in the filesystem.
Only in the end will all remaining dependencies be combined to
make up the entire list of dependencies for that service.
Actually I'd probably be more liberal here and even allow dropping
deps created in the unit file with a .wants masking. The only thing i
would not allow is masking out deps on a unit that are actually
configure on another unit, as well as automatic deps.

I mean, so far the deps we set are combined from:

unit file (1)
+ dropins (2)
+ .wants/ + .requires/ symlinks (3)
+ automatic deps (4)
+ deps configured in other units (5)

I'd allow unsetting deps configured in (1) from (1), (2) and (3). I'd
allow unsetting deps configured in (2) from (2) and (3). I'd allow
unsetting deps made in (3) from (3).

I would not allow unsetting deps made in (1,2,3) with (4) or (5), or
vice versa.

Lennart
--
Lennart Poettering, Red Hat
Christian Seiler
2015-04-23 18:58:14 UTC
Permalink
Post by Lennart Poettering
unit file (1)
+ dropins (2)
+ .wants/ + .requires/ symlinks (3)
+ automatic deps (4)
+ deps configured in other units (5)
I'd allow unsetting deps configured in (1) from (1), (2) and (3). I'd
allow unsetting deps configured in (2) from (2) and (3). I'd allow
unsetting deps made in (3) from (3).
I would not allow unsetting deps made in (1,2,3) with (4) or (5), or
vice versa.
That makes sense, I'll incorporate that.

Christian
Dimitri John Ledkov
2015-04-24 00:58:18 UTC
Permalink
Post by Christian Seiler
Post by Lennart Poettering
unit file (1)
+ dropins (2)
+ .wants/ + .requires/ symlinks (3)
+ automatic deps (4)
+ deps configured in other units (5)
I'd allow unsetting deps configured in (1) from (1), (2) and (3). I'd
allow unsetting deps configured in (2) from (2) and (3). I'd allow
unsetting deps made in (3) from (3).
I would not allow unsetting deps made in (1,2,3) with (4) or (5), or
vice versa.
That makes sense, I'll incorporate that.
I like this as well.
--
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
Christian Seiler
2015-02-16 14:35:50 UTC
Permalink
Post by Lennart Poettering
Post by Christian Seiler
You couldn't override init scripts that way - if you wanted to do that,
you'd have to replace them completely. But if you just want to alter
(or even specify for the first time for certain third-party scripts)
dependency information but keep getting updates for the init script
from the software vendor, this was really, really useful.
Since I never heard anyone asking for this, I doubt it was really that
useful in real life...
Understanding that you don't want to accept this kind of patch, I do
want to disagree here vehemently. On sysvinit systems I've used that
a LOT of times to modify init scripts, both from the distribution and
from third parties. Scripts from the distribution mainly to add some
dependencies due to local configuration, but third-party scripts
because those had either completely broken LSB headers or even
non-existent ones. So at least from my experience, this feature was
_immensely_ useful. And if you search for "insserv/overrides" in your
favorite search engine, you'll find that there are enough hits there
to see that I'm not the only one.

(Now obviously, you don't want to support it, so I'll move on, but I
did want to disagree with the assertion that it wasn't useful.)

Christian
Dimitri John Ledkov
2015-02-16 14:55:12 UTC
Permalink
Post by Christian Seiler
Post by Lennart Poettering
Post by Christian Seiler
You couldn't override init scripts that way - if you wanted to do that,
you'd have to replace them completely. But if you just want to alter
(or even specify for the first time for certain third-party scripts)
dependency information but keep getting updates for the init script
from the software vendor, this was really, really useful.
Since I never heard anyone asking for this, I doubt it was really that
useful in real life...
Understanding that you don't want to accept this kind of patch, I do
want to disagree here vehemently. On sysvinit systems I've used that
a LOT of times to modify init scripts, both from the distribution and
from third parties. Scripts from the distribution mainly to add some
dependencies due to local configuration, but third-party scripts
because those had either completely broken LSB headers or even
non-existent ones. So at least from my experience, this feature was
_immensely_ useful. And if you search for "insserv/overrides" in your
favorite search engine, you'll find that there are enough hits there
to see that I'm not the only one.
(Now obviously, you don't want to support it, so I'll move on, but I
did want to disagree with the assertion that it wasn't useful.)
It is likely that things/scripts that were modified at the time via
such overrides, have systemd units today.
Merging this support today, will land in stable "enterprisy" releases
in 1-2 years time.
By that time, upgrades to that future release is even more likely to
have been moved on to systemd units - or alternative technologies /
implementations all together.
I believe that your concerns and points are valid, but the timing to
implement/merge/support such a use-case upstream is past the point of
no return.
Systems that will upgrade to systemd 219+ will be overwhelmingly from
earlier systemd releases, or at best mixtures of (degrees of) upstart
and/or SysV compliant initscript (with dependencies) in an enforcing
mode.

If you have a strong desire for such a feature, and I presume in
current stable distributions, rather than future stables. It is best
to factor it out into a stand-alone, portable across older systemd
releases, generator, and ship it as stand-alone utility / project that
people can install as an addon to regain compat for that
functionality. And hopefully people will have no need for it in the
stable distros everyone will ship in 2017 onwards.
--
Regards,

Dimitri.

Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
Michael Biebl
2015-02-16 18:12:35 UTC
Permalink
Post by Dimitri John Ledkov
If you have a strong desire for such a feature, and I presume in
current stable distributions, rather than future stables. It is best
to factor it out into a stand-alone, portable across older systemd
releases, generator, and ship it as stand-alone utility / project that
people can install as an addon to regain compat for that
functionality.
I don't think this is really feasible atm. See my earlier comment.
Atm, you can't override orderings/dependencies via drop-ins.

So such a generator would have to recreate the unit files altogether,
replicating what the sysv-generator does.

I agree with Lennart, that adding support to systemd to allow such
overrides via drop-ins/unwants/ or whatever they are called, is
certainly the nicer solution.

That said, as one of the Debian systemd maintainers, I could probably
be convinced to add the insserv override support as a downstream patch
for jessie. We are pretty late into the freeze though, so this would
require an ack from our release managers.

Going forward, I'd like to drop support for insserv compat in jessie+1
as soon as possible. That includes the insserv-generator, which parses
/etc/insserv.conf(.d)
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Jóhann B. Guðmundsson
2015-02-16 11:00:16 UTC
Permalink
Post by Christian Seiler
Hi,
I just noticed that sysv-generator doesn't handle
/etc/insserv/overrides (e.g. older SuSE, Debian) or /etc/chkconfig.d
(e.g. RHEL <= 6, Centos, old Fedora), it just ignores it, thus not
retaining administrator overrides to init script headers. Now
obviously, one can create a native unit file that overrides the sysv
service, but that is not always so nice.
In the simplest case, the init script is trivial and you just create a
simple native service and are better off anyway. But most of the time,
init scripts where you want to override headers are provided by third
parties, and do a lot of involved things, and as an administrator you
don't want to port the old init script yourself, you just want to call
the original one and be done with it. (And even worse, some
third-party init scripts don't even come with LSB headers, even in
2015.)
That's a matter of perception we prefer migrating the legacy sysv
initscript on these parts to take advantage of administrator features
systemd provides.

On top of that this is the first time I have ever heard of this ( as in
you could overwrite lsb headers with configuration snippets in
/etc/chkconfig.d ) and dont recall coming across it in documentation
while handling the migration from legacy sysv init scripts to native
systemd units in Fedora nor has anyone anywhere filed a bug about this
missing for the past 5 years in the downstream bug trackers where I
monitor bugs filed against systemd.

That said adding this support to systemd does not seems justified enough
since a) at one point in time the backward compatibility will be dropped
altogether b) nobody seems to be using this feature of chkconfig
otherwise bugs would have been filed and we would have heard about it by
now.

JBG
Christian Seiler
2015-02-16 11:32:43 UTC
Permalink
resending, didn't go to list the first time (sorry for the duplicate)
Post by Jóhann B. Guðmundsson
Post by Christian Seiler
In the simplest case, the init script is trivial and you just create a
simple native service and are better off anyway. But most of the time,
init scripts where you want to override headers are provided by third
parties, and do a lot of involved things, and as an administrator you
don't want to port the old init script yourself, you just want to call
the original one and be done with it. (And even worse, some
third-party init scripts don't even come with LSB headers, even in
2015.)
That's a matter of perception we prefer migrating the legacy sysv
initscript on these parts to take advantage of administrator features
systemd provides.
Sure, in an ideal world. But as I said in my initial mail, if you have
crappy scripts provided by third-parties, this is not always an option.
And I don't think init scripts are going to fully disappear in the next
10 years, it's not realistic - especially if you look at a lot of
third-party scripts, where the authors appear to have had no clue about
what they were doing.

Christian
Jóhann B. Guðmundsson
2015-02-16 12:09:26 UTC
Permalink
Post by Christian Seiler
Sure, in an ideal world. But as I said in my initial mail, if you have
crappy scripts provided by third-parties, this is not always an option.
And I don't think init scripts are going to fully disappear in the next
10 years, it's not realistic - especially if you look at a lot of
third-party scripts, where the authors appear to have had no clue about
what they were doing.
Initscripts will disappear once we stop provide backwards compatibility
to them.

Regarding authors and initscripts I can safely say after going through
what close to 600 components shipping initscripts in Fedora that the
majority of the authors of those initscript did not have had no clue about
what they were doing when they wrote them.

Ironically the same pattern seems to be emerging amongst unit writers so
as things stand now history is on a path to repeat itself in that regard.

JBG
Continue reading on narkive:
Loading...