state of systemd in Fedora and services pledge

Michał Piotrowski mkkp4x4 at
Wed Feb 23 20:33:33 UTC 2011

2011/2/23 Toshio Kuratomi <a.badger at>:
> On Wed, Feb 23, 2011 at 04:38:50PM +0100, Michał Piotrowski wrote:
>> 2011/2/23 Toshio Kuratomi <a.badger at>:
>> > On Wed, Feb 23, 2011 at 01:30:52AM +0100, Lennart Poettering wrote:
>> >> On Tue, 22.02.11 12:19, Toshio Kuratomi (a.badger at wrote:
>> >>
>> >> > 2011/2/22 Michał Piotrowski <mkkp4x4 at>:
>> >> > > Hi,
>> >> > >
>> >> > > I wonder what is the actual state of Fedora systemd integration? I
>> >> > > hope that there is more systemd native services than listed on
>> >> > >
>> >> > >
>> >> > > Currently I have quite a lot of work, but I make a systemd services
>> >> > > pledge - I'll write three services per week if 10 other people do the
>> >> > > same
>> >> > >
>> >> > >
>> >> > uh... How are you creating the spec file?  In testing, I've yet to get
>> >> > a specfile that performs as expected.  I'd be happy if you could take
>> >> > a look at the proposed guidelines and figure out if this is a
>> >> > guidelines bug, a systemd bug, a testing bug, or a bug in the packages
>> >> > that I'm testing with.
>> >>
>> >> Did you actually check if you had at least chkconfig 1.3.50-1 installed
>> >> when you tested this, as I wrote in the FPC bug?
>> >>
>> >> Also, Michał's work is about adding systemd unit files, not about adding
>> >> SysV init scripts, because those already exist...
>> >>
>> > Okay, I've tried all sorts of different wording to get you to understand
>> > what is being tested.  I'll try one more before giving up:
>> >
>> > Are you proposing that system V init scripts be banned for F15 and that we
>> > do not allow upgrades from F14 to F15, only new installs?
>> >
>> > If you aren't proposing that, then testing that we can successfully upgrade
>> > from a systemVinit script using package to a systemd unit file using package
>> > is a test that needs to pass.
>> I'm not a Fedora developer and I do not know much about RPM's. Could you
>> write something more about what problem you mean?
> If a particular piece of software is going to convert from systemv init
> scripts to systemd unit files we'll end up with two important rpm files.
> One that is before the conversion and has sysv init scripts and one that is
> after the conversion and has systemd unit files.

IFAIU RPM after conversion should have both - sysv init scripts and
systemd services.
Why do you want to remove sysvinit scripts? Both scripts can coexist
without any problem.

> The rpm packages contain small (usually shell) scripts that allow the
> package to register themselves with the init system.  These will turn
> the service on if that's allowed by policy, restart the service if it's
> already running, stop the service before uninstallation, etc.
> The proposed Packaging Guidelines for systemd:
> Needs to contain the necessary scriptlets for packages that use systemd unit
> files.  At the moment, the draft only contains scriptlets for a default-off
> case.  We also need scriptlets for services which autostart and for services
> which bus activate.  Given that FESCo seems to be moving towards a policy
> that allows a broad range of services to autostart, we probably need the
> autostart guidelines in place soon.  The bus activated scriptlets are needed
> but we may be able to delay as it sounds like we only want a few services to
> be bus activated anyway and those services can be started as normal until we
> have guidelines on how they need to be set to autostart.
> The scriptlets that we currently have do not work in testing.  I have tested
> the migration path from a sysv init script using service to an upgraded
> package using systemd unit files and that doesn't work.  at some point
> someone also needs to test the upgrade between systemd unit file using
> services but I personally haven't had time for that yet.  The FPC ticket has
> the steps that would constitute a good test of those services.
> Without guidelines that work, current work to port to systemd unit files
> could have several undesirable effects.  Least critically would be that the
> ported packages would need to be revisited to have their spec files updated.
> Most critically, the unit file using packages would break end users systems
> when they upgrade the package from F15 to F14.

Thanks for the explanation of the problem.

> -Toshio
> --
> devel mailing list
> devel at

Best regards,

More information about the devel mailing list