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

[Thomas H.P. Andersen]

On Thu, May 29, 2014 at 4:30 PM, Andrey Borzenkov <arvidjaar at gmail.com> wrote:
> В 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?

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