Bug#727708: init system discussion status
On 4 January 2014 23:16, Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> wrote:
> On Sat, Jan 04, 2014 at 06:59:46PM +0000, Dimitri John Ledkov wrote:
>> Also it is sad that systemd upstream is actively promoting for
>> everyone to execute runtime checks of is systemd-init pid1,...
> This is done public systemd libraries to become NOPs if not running on
> or not compiled for systemd, to make it easier to integrate
> systemd-related functionality in programs portable to other
> environments. Full original functionality can be always trivially
> restored.
>
> Built-in systemd components do no such checks, and generally are
> written with the assumption that they are using the same systemd
> versions. (What I'm saying is quite inprecise, but because it's not
> the main point, I don't want to go into details.)
>
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?
How much functionality / api is exported by libraries/dbus of systemd
to move components out of the systemd tree and into separate projects.
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. E.g. it would be benefitial for
systemd to support hallyn's cgroupmanager (which can be used
standalone or not).
>> what's systemd version number",
> I'm not aware of any such checks.
>
I'll find references, but I believe some components in KDE starting
doing so upstream which has been reported to me from
ProjectNeon/Kubuntu. I'll follow up more on that.
Again, not sure if this is lack or shared library for logind support,
but a lot of projects were using sd_booted() (pid1 init check) instead
of checking for logind e.g. (access("/run/systemd/seats/", F_OK) >= 0)
It would be easier if software that integrates with individual
services was doing imperical checks of the services it uses, or better
gracefully fail-over at runtime if those fail (e.g. over dbus). Also
logind seat management seems to use "systemd" names instead of
XDG-names (as done in other places) or like a generic name "logind".
Looks untidy, and making DEs claim they "support or require"
systemd-init, when infact they mean logind.
>> granted Martin Pitt did identify this
>> problem and fixed majority of opensource projects to check for the
>> requested/required functionality, instead of arbitrary transitive
>> checks of pid1. This in part enables to run systemd-logind without
>> systemd-init as pid 1.
>>
>> 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.
>> 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)
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?
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?
> [1] http://kawka.in.waw.pl/git/systemd/
> [2] http://cgit.freedesktop.org/systemd/systemd/
>
>> Thankfully it's not a single giant patch as it's
>> done by RedHat for their kernels, but actually git am formatted series
>> of 116 patches[5].
>>
>> The diffstat between:
>> - debian package and git v204 checkout is: 44 files, 246 +, 566 -
>> - fedora 19-204 and v204 tarball: 102 files, 11368 +, 1366 -
>> - rhel 7-beta-src-iso and v207 tarball: 133 files changed, 2364
>> insertions(+), 1686 deletions(-)
>>
>> Which is a significant chunk of fixes. Looking at some of them, they
>> are true gems like "don't truncate and loose multiline syslog
>> messages" which is not fixed in Debian at the moment. Can we please
>> not have journald by default in jessie, cause I don't want my syslog
>> truncated?!
>>
>> 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. 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.
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.
--
Regards,
Dimitri.
Reply to: