В Thu, 29 May 2014 16:11:25 +0200 "Thomas H.P. Andersen" <pho...@gmail.com> пишет:
> On Wed, May 28, 2014 at 3:38 AM, Zbigniew Jędrzejewski-Szmek > <zbys...@in.waw.pl> wrote: > > On Wed, May 28, 2014 at 01:12:23AM +0200, Thomas H.P. Andersen wrote: > >> From: Thomas Hindoe Paaboel Andersen <pho...@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? > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
