On Thu, May 29, 2014 at 4:30 PM, Andrey Borzenkov <arvidj...@gmail.com> wrote: > В 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?
Not a bad idea. If SourcePath is within the sysvinit path then assume a sysv service. Here is the generated unit from "livesys" on f20 btw. We could go for extra checks like if a is set Description it must start with eihter "LSB:" or "SYSV: ". But SourcePath seems like a reliable way to me. # Automatically generated by systemd-sysv-generator [Unit] SourcePath=/etc/rc.d/init.d/livesys Description=LSB: Init script for live image. Before=runlevel3.target runlevel4.target runlevel5.target shutdown.target display-manager.service livesys-late.service Conflicts=shutdown.target [Service] Type=forking Restart=no TimeoutSec=5min IgnoreSIGPIPE=no KillMode=process GuessMainPID=no SysVStartPriority=0 RemainAfterExit=yes ExecStart=/etc/rc.d/init.d/livesys start ExecStop=/etc/rc.d/init.d/livesys stop >> 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
