Mailinglist Archive: opensuse-factory (564 mails)

< Previous Next >
Re: [opensuse-factory] [RFC DRAFT] Phasing out sysvinit
  • From: "Bernhard M. Wiedemann" <bernhardout@xxxxxxxx>
  • Date: Sun, 18 Dec 2011 10:13:33 +0100
  • Message-id: <>
Hash: SHA1

Am 17.12.2011 01:18, schrieb Cristian Rodríguez:
On 17/12/11 17:41, Bernhard M. Wiedemann wrote:

yes most of those are bugs elsewhere..

bugs that only occur because of systemd can not be ignored when you
want to drop the working alternative.

As I understood it, native unit files are not needed for the goal
of fully switching to systemd and dropping sysvinit - so this
step (and all other steps about /etc/init.d/ replacement) should
be optional.

no, there should not be optional, as does solve the problem of
supporting two different ways to do things.

openSUSE is not python (which is claimed to have exactly one way to do
things) - but more like perl with TIMTOWTDI(=There Is More Than One
Way To Do It) philosophy. We have 4 Desktop-Environments, countless
windows-managers, email programs and web-browsers...
So I wonder why having two init systems (that are even mostly
compatible) for some years would be a problem.
There will be extra packages with /etc/init.d/ scripts for a long
time, so we can not just abandon the sysv-compat anyway - openSUSE is
more than the core we ship and we need to consider this in our decisions.

Add documentation, HowTos etc. for developers and users of
systemd and its service files so that they can tweak and extend
their system as easily as with sysvinit. This might be inherently
hard, because some things that used to be in easily changeable
/etc/init.d/boot.* scripts were hardcoded into systemd's C code.

There is more documentation, than the old system ever had,
including full grown how-tos to convert both units and daemons,
example c code, libraries, tools, whatever..

let's have an example - I used to adapt the timeout for mounting my
crypted home partition. By looking at /etc/init.d/boot.crypto I found
that /lib/cryptsetup/boot.crypto.functions contains a TIMEOUT value of
120 seconds, which I then change with a text editor and will thus be
used on next boot.
Systemd does not use /etc/init.d/boot.* files

with "find" I found
/lib/systemd/systemd-cryptsetup (binary - so unreadable) and

which mentions
man 7 systemd.special
but this manual page does not even mention "crypt" once.
And nothing about "timeout" either.

man 1 systemd-ask-password at least mentions a default timeout of 90s,
but how can I be sure that this is the one applied here and how to
adapt it?

googling for systemd cryptsetup timeout
did only find bugreports, but nothing helpful.
So as you know the extensive documentation better, you can certainly
give a pointer to the page describing how to do this simple task.

This step will ideally still be some years ahead,

it cannot be some years ahead, we cannot support two systems for
large periods of time, with the current amount of developer power
is imho, completely out of the question.

Where does the support effort come from (aside from fixing bugs that
need fixing anyway)?
I can see some effort in maintaining /etc/init.d/boot.* files together
with their systemd equivalent.
And some more effort if you start converting everything to service
files (which IMHO is not needed so far)

so that as many use-cases as possible will be known to work with

your sugestion will actually delay those cases being known.

are we in a hurry?

People don't
like being forced into something that does not work properly.

It works, it has bugs like any software, and people complain for
everything either if it works or not, without having any idea where
the problem is.

If they dont like it, they are free to find another distribution
that does not "force" you to use it, that currently reduces to
debian, gentoo, an a few other players. (ubuntu has upstart,
mandriva,fedora, have systemd..etc)

I run all my headless servers with Debian/stable, because they usually
do sane decisions, have long maintenance and an abundance of packaged
I'd love to have a green alternative.
openSUSE+Evergreen is currently closest to being one.

Bernhard M.
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla -

To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
This Thread