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

Christian Seiler christian at iwakd.de
Sun Feb 15 08:21:34 PST 2015


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


More information about the systemd-devel mailing list