Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
TL;DR: Thoughts on using systemd .service files on non-Linux ports.
On Tue, Oct 29, 2013 at 09:20:10AM +0100, Lucas Nussbaum wrote:
> Note that there are two options that could be explored, to remove the
> need to maintain init scripts:
> - generating sysvinit scripts from systemd service files or upstart job
> files at build time (this was explored, for systemd service files,
> during a GSoC project in 2012, without much success)
> - having a .service/job files runtime interpreter (that sounds quite
> promising)
>
> Even if it cannot be used for all services, using such as interpreter
> could maybe provide an easy support path for sysvinit on non-linux
> platforms for a large number of "simple" services.
>
> There's a subthread about that starting at
> https://lists.debian.org/debian-devel/2013/05/msg01309.html
> Helmut Grohne (Cced) did most of the work on analyzing those possibilities.
Thanks for inviting me to speak up here. Lucas asked me to summarize my
analysis of systemd/sysv integration earlier and I'll be giving this
summary (written for Lucas at that time) below.
For better separation of facts and opinion, let me point out my
motivation for working on this aspect. I believe that the declarative
service configuration of systemd and upstart is superior to init shell
scripts. Consequently, dropping the need for init shell scripts is the
only way to improve the situation (imo). Lacking time, I mostly
neglected upstart.
On 23/08/13 at 22:32 +0200, Helmut Grohne wrote:
> The existing converter (GSOC) can be found at
> https://github.com/akhilvij/systemd-to-sysvinit-converter.
>
> My analysis of this project:
> https://lists.debian.org/debian-devel/2013/05/msg01309.html
> This includes a drafted idea on how to do runtime conversion.
>
> Implementation details on runtime conversion: (last pragraph)
> https://lists.debian.org/debian-devel/2013/05/msg01337.html
>
> Random details about service file conversion issues:
> https://lists.debian.org/debian-devel/2013/05/msg01334.html
> Important point over here: In .service files important dependency
> information has been elided by socket activation. Socket activation is
> official part of the dependency tree and any conversion utility that
> does not do socket activation will not produce correct boot ordering.
>
> Statistical analysis of existing .service files in Debian.
> https://lists.debian.org/debian-devel/2013/07/msg00436.html
>
> .service file parser written in C, could be used as a starting point.
> https://lists.debian.org/debian-devel/2013/07/msg00429.html
>
> I presume that you are preparing arguments for a discussion with the
> CTTE about how to move forward with /sbin/init. The question of whether
> or how to support systemd .service files on non-Linux platforms will be
> asked over there.
>
> The biggest issue I see here is the socket activation. It is mandatory
> for syslog, so no service will declare a dependency on syslog and just
> assume it to be present. On a technical level implementing socket
> activation on non-Linux platforms is possible. It would require a super
> server (similar to inetd) to be started early on and it would start
> .service files on request by other interpreted .service files when
> executed as init scripts. This amounts to reimplementing a fair part of
> systemd. The only alternative would be to annotate .service files with
> the missing dependency information, but which would likely be wrong most
> of the time.
>
> I guess that an implementation that allows socket activation would be
> able to support around 50% of the currently existing .service files.
>
> Bear in mind that systemd is a rapidly moving target. When I talked to
> Lennart about the idea of a portable .service file interpreter, he
> summarized future extensions to systemd that would raise the bar. The
> next issue will likely be the tight integration with dbus and later
> kdbus (the kernel implementation of dbus). By the time we would have an
> implementation featuring socket activation, we will likely need it to do
> dbus activation as well.
Having read the parts of the ctte bug, it feels odd to preclude the
option of supporting multiple init systems from discussion or
consideration. If Debian is to support only one init system and that one
init system is systemd, then given my above analysis it will be very
hard for non-Linux ports to catch up. I argue that in this case we
should consider dropping support for non-Linux ports. So if we really
are considering such an outcome, why not consider the outcome of
supporting multiple init systems (but maybe only one per architecture)?
This would become radically easier if gnome were to become Architecture:
linux-any.
In any case, feel free to ask me for answers or help with respect to
possible integration of systemd .service files in a non-Linux
environment.
I hope that this mail moves the discussion/decision forward.
Helmut
Reply to: