[systemd-devel] [PATCH] [RFC] Move handling of sysv initscripts to a generator

Andrey Borzenkov arvidjaar at gmail.com
Thu May 29 07:30:57 PDT 2014


В Thu, 29 May 2014 16:11:25 +0200
"Thomas H.P. Andersen" <phomes at gmail.com> пишет:

> On Wed, May 28, 2014 at 3:38 AM, Zbigniew Jędrzejewski-Szmek
> <zbyszek at in.waw.pl> wrote:
> > On Wed, May 28, 2014 at 01:12:23AM +0200, Thomas H.P. Andersen wrote:
> >> From: Thomas Hindoe Paaboel Andersen <phomes at gmail.com>
> >>
> >> Reuses logic from service.c and the rc-local generator.
> >>
> >> Note that this drops reading of chkconfig entirely.
> > How likely is this to cause regressions in existing distributions?
> >
> >> It also drops reading
> >> runlevels from the LSB headers. The runlevels were only used to check for
> >> runlevels outside of the normal 1-5 range and then add special dependencies
> >> and settings. Special runlevels were dropped in the past so it seemed to be
> >> unused code.
> >>
> >> Also note that this code behaves differently to the old if an initcsript
> >> and native unit exist with the same name. Before the initscript would be
> >> ignored but now a .service file is created in /run which will override
> >> the native unit.
> > This is a total no-no. This would immediately break existing setups,
> > becuase since forever this has been documented and advertised as a
> > compatibility mechanism.
> >
> >> The old code dealing with initscripts are left in for now as the generator
> >> will run first and the old code will then ignore the initscripts since
> >> unit files exist for them. I will add another patch to rip the old code out
> >> later.
> > It would be nice to have this counterpart too, since then it would be easier
> > to tell how much complexity and existing code we are removing. I think that
> > there's general agreement to the idea of moving sysv support to a generator,
> > the question is only if we can do it without significant breakage.
> 
> I cleaned up the code for yours and Peeters comments. Units generated
> from initscripts no longer take precedence over native units.
> 
> Ripping out the old code was harder than I thought though. The Service
> struct contains a few sysv-specific fields that were filled directly
> when the initscripts were parsed. Only one of them can be set from a
> .service file. If we want to keep them all then we need to add options
> for them in the .service file. IMO all but one are irrelevant with the
> generator. The relevant one left is is_sysv. It is used to prevent the
> sysv unit from garbage collection and to refuse socket activation for
> sysv services. The remaining fields (sysv_has_lsb, sysv_enabled,
> sysv_start_priority_from_rcnd, sysv_start_priority, sysv_runlevels)
> are now only used in service_dump and I cannot see any code in systemd
> making use of the dumped values.
> 
> Would it be acceptable to just drop the fields only used in service_dump?
> Is it okay to add a "SysV=true/false" option to .service?

Could it make use of SourcePath to avoid adding special case variable?

> What about the "SysVStartPriority=" option set in native .service's?
> The generator does not know about non-generated units with such a
> value set so it cannot take them into account when converting start
> priority to before/after. Should the manager itself try to reorder all
> units with a sysv priority later?
> 


More information about the systemd-devel mailing list