[systemd-devel] sysv-generator: doesn't handle /etc/insserv/overrides or /etc/chkconfig.d

[Christian Seiler]

Hi,

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