Bug#727708: init system discussion status
On Sun, Jan 05, 2014 at 12:54:04AM +0000, Dimitri John Ledkov wrote:
> So components inside systemd-source tree do not follow what's advised
> to all other projects: e.g. link or statically include sd_* helper
> files, and perform runtime checks?
The advice for other projects assumes that systemd is
optional. systemd components assume that they will be installed as
part of systemd, so such compile time checks would make little sense.
Various configure swithes can be used to disable components, but not
the main "systemd" part.
> How much functionality / api is exported by libraries/dbus of systemd
> to move components out of the systemd tree and into separate projects.
systemd components share the same codebase, and they all make
extensive use of shared functionality (src/shared part in the source
tree, but not only there) which has does not have any stable external
API. So it's not possible to "move out" any of them in any practical
sense. This is a bit like with the kernel.
> Or, what's more interesting, projects external to systemd integrating
> on the same level. E.g. in upstart, all common code is factored into
> stable-api/abi libnih, which is then free to use by anyone (e.g. event
> bridges, mount helpers, etc.) and all communication to/from upstart is
> exported via dbus IPC (on private socket or systemd dbus). If
> code-sharing is only happening by being part of the systemd codebase,
> that also increases barrier of entry.
In systemd most of the D-Bus interface, share-library interface,
and various other APIs are stable, but the internal C API is not. It
simply changes too fast and it is not possible to make it public.
> E.g. it would be benefitial for systemd to support hallyn's
> cgroupmanager (which can be used standalone or not).
I'm not really an expert in this area, so please don't take my words
as authoritiative, but... No, it wouldn't. systemd (the binary running
as PID 1) uses cgroup functionality extensively. If it was to become
external (in a seperate process) some sort of of synchronous protocol
would have to be used, complicating things immensly, for no gain. If
it was to be used as a library, that is in theory possible, but we
would replace working code with something external and not even
working at this point. Also cgmanager is supposed to follow a
different philosophy.
> >> Also which upstream are staying with? systemd upstream git history[4]
> >> has only one branch, which is linear with linear version number
> >> increments, without any stable release branches or other indications
> >> of which patches are stable (or possibly security) bugfixes.
> > git notes are used to mark backport-worthy commits. See
> > http://lists.freedesktop.org/archives/systemd-devel/2013-September/013188.html.
> > We currently mark patches as bugfixes (which includes fixes for bugs
> > present in the latest release, but not those introduced later),
> > or documentation and performance improvements.
> >
>
> Thank you for this link, I was not aware of this policy. This is the
> first time i see git-notes used for tracking bugs needed for
> stable/security/documentation, and it was hard for me to find.
> Does also mean such stable maintenance only started in September 2013?
> Or some other scheme used before that? Current debian version of
> systemd is v204, tagged in May 2013.
In this form, yes.
> >> Fedora 19 appears to be packaging patches from v204-stable branch
> >> which I can't find anywhere public.
> > It's my private branch I generate Fedora packages from [1]. It's the
> > same content as in Fedora git repos [2], but in a more convenient form
> > for me. I talked with other systemd maintainers in Fedora about making
> > it more official and public, but we haven't found the time to do it
> > yet. If it was to be useful to other people, it can certainly be done.
> >
>
> Thank you for pointing out where it is. Maybe add a URL in the spec
> file pointing to where it is? Cause I've search hard and didn't manage
> to find where it's maintained.
> (or push a mirror to github systemd projects or some other place if
> you require team commit access)
Either that, or fedorahosted, or the upstream... We'll have to pick something,
yes.
> I guess that also makes the RHEL patch series based on yours/fedora
> releases. Are there changes that are in RHEL7 and not in fedora, your
> fork, and upstream?
AFAIK, access to RHEL source code would require a subscription. I don't
know what RHEL packages include, sorry.
> Debian SytemD maintainers, has the ~116 fedora's stable fixes patch
> series been reviewed and decided to not be applied? What about stable
> branches from other distributions, have those been investigated?
Normally maintainers from various distros (including Fedora and Debian)
upstream all bugfix patches. So pulling from upstream is enough.
> >> In my opinion it is unwise to ship something into stable, ahead of
> >> upstream doing so for their support customers (RedHat Enterprise
> >> Linux).
> > I think you're overestimating the (direct) influence of Redhat on
> > system upstream bug fixes. There are patches ("don't truncate and
> > loose multiline..." being one of them) done as a result of a bug
> > reported in RHEL, but their number is insignificant compared to the
> > number of bugs reported and fixed in Fedora, the upstream bugtracker
> > and other distro's bugtrackers. Actually Debian is suffering here
> > becuase of the large version gap to current upstream. It makes it
> > much harder to reproduce bugs, and if fixes are done, additional
> > work is required in backporting. After various codebase cleanups
> > and the the post-208 rewrite to use libsystemd-bus in systemd
> > components, any patch which touch dbus codepaths has to be rewritten
> > rather than cherry-picked to such old versions.
> >
>
> This confirms that systemd is not generic across all upstreams and all
> distributions, and everyone is maintaining their own (in part
> influenced by release cadence, and well distro-specific integration)
> Having git repos, or even distro specific branches on Freedesktop.org
> would help. Since well, it's suppose to be a cross distro
> collaboration projects. I see little point in each distribution
> redoing it's own stable maintainance.
AFAIK, apart from patches which are non applicable for upstream, all
distributions basically pick some release of systemd and cherry-pick a
subset of bugfix and feature patches. This depends on the release
cadence and stability policies of those distributions. E.g. Arch
packages the latest git, Fedora usually the latest systemd release at
the time that that Fedora version was released, etc. Nobody ever said
that the same systemd version should be used everywhere. What is
shared, are the unit files, systemd support in other software, and
administrator knowledge. The fact that different distributions have
different systemd versions (and also slightly different bugs), doesn't
change that, it seems completely natural to me.
That said, I'm all for improving cross-distro collaboration on
systemd. I'm sure that if Debian picks systemd as the default, it will
be beneficial to both sides.
> A lot of debian-specific patches
> would be gone, if systemd did look up daemons based on path instead of
> hardcoded paths, but alas that has been rejected upstream. I don't see
> why we should be pointlessly moving our binaries around, or spend time
> patching all unit files (which i guess would then also be claimed as
> "not supported" by lennart). This diminishes in my view that systemd
> is a coherent / all-unifying cathedral, suitable as-is to all
> distributions.
>
> I am sorry for overestimation, my biggest worry is RHEL customer bugs
> and their fixes that are yet to come once systemd is used by those
> deployments.
"lennart", by which you mean Lennart Poettering I guess, does not
provide support for Debian, Debian maintainers do. Even in Fedora,
Lennart Poettering doesn't write unit files, individual packagers do.
Anyway, the $PATH issue is rather minor, and you're trying to make
it into something fundamental.
I hope you don't want to limit Debian to things done by Redhat and
well tested by their customers. The upstream git is where development
and bugfixes happen (no CLA :), no fuss).
[Quoting Russ Albery:]
> Patching upstream unit files to change paths is trivial, but even better
> would be to convince upstream to substitute in the proper path when
> building the unit file.
Exactly. This is what systemd does when with its own unit files.
See [1] for an example.
[1] http://cgit.freedesktop.org/systemd/systemd/tree/units/console-shell.service.m4.in?id=HEAD
> post-208 rewrite, is interesting, burning bridges with dbus? no
> freedesktop spec, making a dbus-like implementation which is entirely
> unportable to other operating systems (BSD, Mac OS X, Windows) makes
> it entirely unattractive to a lot of cross-platform toolkits like Qt
> or projects that currently do support those platforms. Standardizing
> on a toolkit/ecosystem marshaling (GVariant), despite not being
> political, looks odd from cross-platform point of view. Does that also
> mean that projects linking against libdbus1 cannot talk to systemd
> components native, without compat translator running on the systemd
> side?
>
> I guess I have to now study kdbus more, since once again it's pulled
> into systemd software collection without real need to do so. There I
> was to think it will just be a bi-directional async IPC method to talk
> to the kernel, instead of e.g. using syscalls / uevents.
The fact that systemd switches D-Bus libraries internally should be
mostly invisible fromt he outside. Bridges to D-Bus are not burned,
even with kdbus, since existing D-Bus clients still work and a
translator is provided. Other D-Bus libraries might implement native
kdbus support, but this is not crucial for anything.
kdbus is Linux specific, but as it was stated many times, systemd uses
Linux specific functionality where it is useful. Contrary to what you
write, there are good reasons for kdbus.
Zbyszek
Reply to: