Re: systemd (Was Re: tmpfs for strategic directories)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 25.05.10 13:15, Simo Sorce (ssorce@xxxxxxxxxx) wrote:

> > My one concern about the current discussion is that the decision to
> > move to systemd in the timeframe of F14 is being rushed ahead of the
> > aforementioned technical judgement.  I can understand your personal
> > enthusiasm for the move as you are intimately familiar with systemd.
> > But I'm not sure its adequate to rush ahead until we all have a better
> > feel on how this works in practise... and how much work its going to
> > take to convert all our existing packages to systemd styled startup.
> > The back and forth on your blog between yourself and Tim Waugh about
> > cups service activation, for example, is something I think we all need
> > to understand.  I think there is a lot buried in that discussion about
> > how complex some of our existing services are going to look under
> > systemd styled configuration.
> 
> I second that.
> 
> I'd like to remember that there are *many* upstreams are going to
> resistant to this change. A lot of upstream projects need to be
> compatible to a lot of Linux and Unix systems, even old ones, so before
> they move they want guarantee that this is really going to be the next
> thing. That means that until most distributions start using systemd
> they are not going to do the work.

They don't *need* to move. It's not an exclusive disjunction, that you'd
have to support either systemd or not systemd. You can easily support
both systemd activation and classic sysv from the same binary. The 10
daemons we have patched so far only needed about 10 lines of changes
each to become socket-activatable. And those changes are nops unless
$LISTEN_FDS is set.

Or in other words: moving to systemd is a gradual process, where for
every service we can decide indivdually how we want to do it:

1) continue use a classic sysv init script
2) provide a native unit file
3) provide a native unit file and do socket/bus based activation

And all that for the same binary.

As mentioned I have now patched the 10 daemons or so we ship by default
(and a few more) to become socket activatable. If we can merge those
upstream and into our packages we already are a big step ahead and
everything else can come later.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux