Jessie without systemd as PID 1?

[Svante Signell]

Hello,

I'm about to install Debian Jessie/testing on a brand new (powerful)
computer and don't want to have systemd running as PID 1. Is the only
way to do that now is to install with the installer, getting
systemd-sysv as PID 1, and later install sysvinit-core, systemd-shim
etc?

[Cyril Brulebois]

Post by Svante Signell
I'm about to install Debian Jessie/testing on a brand new (powerful)
computer and don't want to have systemd running as PID 1. Is the only
way to do that now is to install with the installer, getting
systemd-sysv as PID 1, and later install sysvinit-core, systemd-shim
etc?

I suppose that's correct. systemd is installed during the bootstrap
phase (see https://lists.debian.org/debian-boot/2014/08/msg00242.html
and follow-up).

Mraw,
KiBi.

[Steven Chamberlain]

Hi,

[...] only way to do that now is to install with the installer, getting
systemd-sysv as PID 1, and later install sysvinit-core, systemd-shim
etc?

I've been dreaming of #758116 (allowing to select Debian Blends
selection during installation) and having as one of the options, a new
Blend perhaps called "Debian alt-init", with one of more 'flavours' that
each would install an alternative init system and its dependencies.

That would happen after d-i has already installed the base system,
including systemd packages, but the idea is that those would be removed
before the installed system is booted for the first time.

Could it really be this simple? Is anyone crazy enough to help make
this happen? And a sponsor who could help with an ITP? I've put
together the beginnings of a Blends package here, completely untested
yet but just in the hope of maybe getting something started:
http://pyro.eu.org/debian/pool/main/d/debian-altinit/

Thanks,
Regards,

[Mike Gabriel]

Hi Steven,

Post by Steven Chamberlain
Hi,

[...] only way to do that now is to install with the installer, getting
systemd-sysv as PID 1, and later install sysvinit-core, systemd-shim
etc?

I've been dreaming of #758116 (allowing to select Debian Blends
selection during installation) and having as one of the options, a new
Blend perhaps called "Debian alt-init", with one of more 'flavours' that
each would install an alternative init system and its dependencies.
That would happen after d-i has already installed the base system,
including systemd packages, but the idea is that those would be removed
before the installed system is booted for the first time.
Could it really be this simple? Is anyone crazy enough to help make
this happen? And a sponsor who could help with an ITP? I've put
together the beginnings of a Blends package here, completely untested
http://pyro.eu.org/debian/pool/main/d/debian-altinit/
Thanks,
Regards,

as I am currently working on a thinclient environment for X2Go which
needs such an alt-init approach beyond wheezy, I will be happy to
help-out with sponsoring and testing.

Greets,
Mike
--
DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: [phone]

GnuPG Key ID 0x25771B31
mail: ***@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Michael Biebl]

Post by Mike Gabriel
as I am currently working on a thinclient environment for X2Go which
needs such an alt-init approach beyond wheezy, I will be happy to
help-out with sponsoring and testing.

Just curious: Why does X2Go/your thinclient environment need an
alternative init? Would be interested to know more about the technical
problems you are having.

[Steven Chamberlain]

Hello,

Post by Mike Gabriel
as I am currently working on a thinclient environment for X2Go which
needs such an alt-init approach beyond wheezy, I will be happy to
help-out with sponsoring and testing.

Great! I was quite sure there will be users who need such a setup for
backward-compatibility. d-i support for Blends sounds like a really
easy way that doesn't require custom install discs.

(If other people have good uses cases for this, please mention them).

The systemd-must-die 'anti-package' tried to do this another way and was
rejected. I hope a Blend would be a more constructive approach. I'm
thinking sysvinit would be the easiest 'flavour' to implement for
jessie, but others are possible, probably only using legacy Sys-V init
compatibility rather than native service files, for now.

sysvinit scripts will still be in use on the kfreebsd and hurd ports for
jessie, so most packages will still ship them even if they have systemd
units also.

We have a tech-ctte resolution in our favour, that reasonable changes
should be accepted into packages to make sure alternative init systems work.

I don't currently expect GNOME to work properly without systemd, I'd
prefer to focus on other desktops instead, but if GNOME's basic
functionality still works that would be nice. (I wonder if the
bugreport template could mention if a non-default init system is used).

I'm going to have a read over ITP procedure, mentors.d.n and Blends
documentation and then I will get back to you.

Thanks!
Regards,

[Mike Gabriel]

Post by Steven Chamberlain
[...]
I'm going to have a read over ITP procedure, mentors.d.n and Blends
documentation and then I will get back to you.

Great. Please do!

Mike
--
DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: [phone]

GnuPG Key ID 0x25771B31
mail: ***@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Thorsten Glaser]

Post by Steven Chamberlain
rejected. I hope a Blend would be a more constructive approach. I'm
thinking sysvinit would be the easiest 'flavour' to implement for

Actually, I think it=E2=80=99s the hardest one.

All others will be task selections run after debootstrap.

Changing the init system in d-i would be done by passing
--include=3Dsysvinit-core --exclude=3Dsystemd-sysv and things
like that (the exact set to be determined by people in
the know).

Oh, and afterwards ensure systemd is not re-added. The
prevent-systemd-* package set can do this in three steps,
although I don=E2=80=99t currently see even prevent-systemd-running
(Conflicts mostly with systemd-sysv) being accepted, so
you=E2=80=99d have to pregenerate some APT pinning configuration
and hope it holds.

bye,
//mirabilos
--=20
Yes, I hate users and I want them to suffer.
=09-- Marco d'Itri on gmane.linux.debian.devel.general

[Ansgar Burchardt]

Post by Thorsten Glaser
Oh, and afterwards ensure systemd is not re-added. The
prevent-systemd-* package set can do this in three steps,
although I don’t currently see even prevent-systemd-running
(Conflicts mostly with systemd-sysv) being accepted, so
you’d have to pregenerate some APT pinning configuration
and hope it holds.

Do you suggest to also add pinning configuration in order to prevent
sysvinit or upstart being installed accidently by default?

It's not in most users' interest to switch init systems without
intention, but could happen in unstable when dependencies are
temporarily not satifiable otherwise...

scnr,
Ansgar

[Thorsten Glaser]

Post by Svante Signell
It would be nice to have the same init system:sysv-core, as well as the
same default desktop:mate-desktop-environment (including accessibility
enhancements), for all arches: Linux, kFreeBSD and Hurd :-) If possible,
this could be an option in the advanced menu of the installer.

Right, but we need multiselect. For example, the user may want
to choose a desktop, an init system, and another option.

This is like with the Grml boot menu, which always annoys me
as I cannot select, for example, toram and nofb at the same
time without manually editing the command line. (And even with
nofb, sometimes I get more than 80x25=E2=80=A6 but that=E2=80=99s neither h=
ere
nor there.) We need additive choices.

Post by Svante Signell
Do you suggest to also add pinning configuration in order to prevent
sysvinit or upstart being installed accidently by default?

Probably. At least when the user made an active decision to
choose one init system during installation, no matter which
one they chose.

Post by Svante Signell
It's not in most users' interest to switch init systems without
intention, but could happen in unstable when dependencies are
temporarily not satifiable otherwise...

Indeed.

Post by Svante Signell
scnr,

Schulljung? :D

bye,
//mirabilos
--=20
=C2=ABMyISAM tables -will- get corrupted eventually. This is a fact of life=
=2E =C2=BB
=E2=80=9Cmysql is about as much database as ms access=E2=80=9D =E2=80=93 =
=E2=80=9CMSSQL at least descends
from a database=E2=80=9D =E2=80=9Cit's a rebranded SyBase=E2=80=9D =E2=80=
=9CMySQL however was born from a
flatfile and went downhill from there=E2=80=9D =E2=80=93 =E2=80=9Cat least =
jetDB doesn=E2=80=99t claim to
be a database=E2=80=9D=09=E2=80=A3=E2=80=A3=E2=80=A3 Please, http://deb.li/=
mysql and MariaDB, finally die!

[Svante Signell]

Post by Thorsten Glaser

Post by Svante Signell
It would be nice to have the same init system:sysv-core, as well as the
same default desktop:mate-desktop-environment (including accessibility
enhancements), for all arches: Linux, kFreeBSD and Hurd :-) If possible,
this could be an option in the advanced menu of the installer.

Right, but we need multiselect. For example, the user may want
to choose a desktop, an init system, and another option.

Some food for thought about systemd:
You might have seen this http://ewontfix.com/14
but have you seen this http://ewontfix.com/15
or this http://boycottsystemd.org/

Having a systemd-free option for Debian Jessie is becoming more and more
important. Otherwise (Debian) users might do as recommended in the third
link: Boycott distros that use systemd.

[Rens Houben]

... I thought we'd all agreed to stop bringing up tired arguments that
nobody but the "systemd MUST DIE" crowd really wants to hear anymore.

Post by Svante Signell
You might have seen this http://ewontfix.com/14
but have you seen this http://ewontfix.com/15
or this http://boycottsystemd.org/

"Open source Tea Party". That explains *so* much...

Post by Svante Signell
Having a systemd-free option for Debian Jessie is becoming more and more
important. Otherwise (Debian) users might do as recommended in the third
link: Boycott distros that use systemd.

"If we keep systemd, people who want to boycott systemd will boycott
us." Seriously, can we stop with the circular arguments as well?

[Martinx - ジェームズ]

Hi!

I'm wondering here... Lets suppose I NEED to use sysvinit, with Debian 8.

If so, can I just run: `apt-get install sysvinit-core` to get rid of
systemd as my INIT?

If yes, will this be support until... Let's say, Debian kFreeBSD still
remains around...?

Also, why not have a system like "/etc/alternatives", or "dpkg-reconfogure
alt-init" (just like "dpkg-reconfigure gdm/kdm"),so people can still choose
between sysvinit / systemd as their default INIT? Maybe during install
time!?

Listen, I'm not a systemd-hater (or lover) but, I'm just saying that, for
safety, I think we need to keep `sysvinit-core` working until ~2020. Just
in case... I'm not saying NO to systemd, I'm just saying, not now
(specially if it if brings some level of instability here and there)...

Long life to Debian / Ubuntu!

BTW, my first message to this list... :-)

Thanks!
Thiago

In other news for Wed, Sep 03, 2014 at 11:11:30AM +0200, Svante Signell
... I thought we'd all agreed to stop bringing up tired arguments that
nobody but the "systemd MUST DIE" crowd really wants to hear anymore.

Post by Svante Signell
You might have seen this http://ewontfix.com/14
but have you seen this http://ewontfix.com/15
or this http://boycottsystemd.org/

"Open source Tea Party". That explains *so* much...

Post by Svante Signell
Having a systemd-free option for Debian Jessie is becoming more and more
important. Otherwise (Debian) users might do as recommended in the third
link: Boycott distros that use systemd.

"If we keep systemd, people who want to boycott systemd will boycott
us." Seriously, can we stop with the circular arguments as well?
--
Rens Houben | opinions are mine
Resident linux guru and sysadmin | if my employers have one
Systemec Internet Services. |they'll tell you themselves
PGP key at http://proteus.systemec.nl/~shadur/shadur.key.asc
--
with a subject of "unsubscribe". Trouble? Contact

[Simon McVittie]

I'm sure we've been over this many times already.

Post by Martinx - ジェームズ
If so, can I just run: `apt-get install sysvinit-core` to get rid of
systemd as my INIT?

Yes.

Post by Martinx - ジェームズ
If yes, will this be support until... Let's say, Debian kFreeBSD still
remains around...?

That's up to the sysvinit and systemd-shim maintainers and how well they
can keep those packages working. If systemd-shim ceases to be a viable
alternative way to run systemd-logind, then you might lose other
packages as a result of this dependency stack:

(stuff that needs logind) -> libpam-systemd -> systemd-sysv |
systemd-shim

(as part of the general principles of "things that don't work get
dropped" and "things that depend on particular functionality should
depend on the package providing that functionality")

If your system doesn't contain anything that needs systemd-logind, then
that dependency stack doesn't exist on your system.

Post by Martinx - ジェームズ
Also, why not have a system like "/etc/alternatives", or
"dpkg-reconfogure alt-init" (just like "dpkg-reconfigure gdm/kdm")

Because not all of the alternatives are equally technically suitable for
everything. With alternatives, there would be no way to express the
dependency relationship "package foo really does need systemd to be pid
1" (or conversely, "foo needs sysvinit-core to be pid 1", which should
probably be the case where e.g. foo = rcconf).

Currently that's spelled like "foo Depends: systemd-sysv"; but if
systemd-sysv and sysvinit-core were co-installable, and you had
systemd-sysv and sysvinit-core installed and sysvinit-core selected to
provide the alternatives, then the dependency would be satisfied, but
foo wouldn't work.

S

[Holger Levsen]

Hi Svante,

Post by Svante Signell
You might have seen this http://ewontfix.com/14
but have you seen this http://ewontfix.com/15
or this http://boycottsystemd.org/
Having a systemd-free option for Debian Jessie is becoming more and more
important. Otherwise (Debian) users might do as recommended in the third
link: Boycott distros that use systemd.

debian-devel@ is for the development of the Debian distribution, not for
ranting. Please take your rants elsewhere. It's tiring and a waste of your and
many other peoples time. But it wont change things. Code changes things in
Debian.


thxgoodybe,
Holger

[Svante Signell]

Post by Holger Levsen
Hi Svante,

Post by Svante Signell
You might have seen this http://ewontfix.com/14
but have you seen this http://ewontfix.com/15
or this http://boycottsystemd.org/
Having a systemd-free option for Debian Jessie is becoming more and more
important. Otherwise (Debian) users might do as recommended in the third
link: Boycott distros that use systemd.

ranting. Please take your rants elsewhere. It's tiring and a waste of your and
many other peoples time. But it wont change things. Code changes things in
Debian.

Ok, these locks was maybe a little to much for some people. I'm sorry
for that. Anyway the TC decision remains that alternative init system
should be allowed, and I'm trying to find out how many of debian users
and developers are interested in working together with me on such a
solution. Best would be to have an option in the installer (hidden by
default). So this question _is_ relevant here for development of the
Debian distribution: debian-devel.

[Noel Torres]

On Wednesday, 3 de September de 2014 16:21:31 Svante Signell escribió:
[...]

Post by Svante Signell
should be allowed, and I'm trying to find out how many of debian users
and developers are interested in working together with me on such a
solution. Best would be to have an option in the installer (hidden by

[...]

I volunteer to test this, not for contributing (I am not a programmer), for a
very simple reason: I do not want my long-running servers (and those of my
clients) to be rebooted for something that should be so simple as upgrading a
service or applying some non-kernel security patch.

I may have (I agree I have) some conservative thinking. I've been well against
network-manager messing my interfaces and I'm against systemd as well, but I
really think the Unix way, when properly implemented, is the way to go. And if
it does not work, make it work instead of building a dinosaur and force
dependencies into it (and yes, I'm pointing at you, Gnome Debian packagers,
both for network-manager and systemd).

In resume: count on me to test and check and report bugs and triage.

Noel
er Envite

[Marco d'Itri]

Post by Svante Signell
Having a systemd-free option for Debian Jessie is becoming more and more
important. Otherwise (Debian) users might do as recommended in the third
link: Boycott distros that use systemd.

And I strongly encourage them to do this: we aim to be universal but we
cannot reasonably fit everybody's needs.

https://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysvinit-core+systemd-shim&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

[Steve Langasek]

Post by Marco d'Itri

Post by Svante Signell
Having a systemd-free option for Debian Jessie is becoming more and more
important. Otherwise (Debian) users might do as recommended in the third
link: Boycott distros that use systemd.

And I strongly encourage them to do this: we aim to be universal but we
cannot reasonably fit everybody's needs.
https://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysvinit-core+systemd-shim&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

Please stop using graphs showing how various teams have forced systemd onto
users' systems as if it is somehow a democratic endorsement of the outcome.

[Marco d'Itri]

Post by Steve Langasek

Post by Marco d'Itri
https://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysvinit-core+systemd-shim&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

Please stop using graphs showing how various teams have forced systemd onto
users' systems as if it is somehow a democratic endorsement of the outcome.

I am not sure about how the concept of democracy applies to this, but
the graph clearly shows that nobody is being forced to do anything and
indeed about 4000 users choose to install systemd-shim and to not use
systemd.

[Cameron Norman]

Post by Marco d'Itri

Post by Marco d'Itri
https://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysvinit-core+systemd-shim&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
Please stop using graphs showing how various teams have forced
systemd onto users' systems as if it is somehow a democratic
endorsement of the outcome.

I am not sure about how the concept of democracy applies to this, but
the graph clearly shows that nobody is being forced to do anything and
indeed about 4000 users choose to install systemd-shim and to not use
systemd.

Ok, let me explain Steve's POV. Many packages depended on
libpam-systemd before systemd-shim was ever in the archive, leading to
systemd-sysv being installed by a normal dist-upgrade on Sid (and,
although I am not sure, testing). The alternative was often to have
GNOME or Network Manager removed, two very popular packages (and the
latter quite important). Even after systemd-shim was uploaded to the
archive (still at logind v204 here), libpam-systemd depended on
"systemd-sysv | systemd-shim". This meant that users' systems would
switch init systems on a normal dist-upgrade *unless* they manually
intervened and knew which package they had to install to avoid that.
Finally, systemd v208 was uploaded to unstable with an unconditional
dependency on systemd-sysv. All of these actions led to users
experiencing a change of init system before they had taken action to
change init systems, which means that the graphs are not reliable in
claiming that the majority of users wanted systemd as their init system.

I can not speak for Steve, but I recognize that some or all of those
actions above were called for. The final one especially (systemd v208
upload), since their was ample warning and communication (something
like one or two months I think), the move was a long time coming, and
systemd was chosen as the default init system by then (not true for the
other two actions).

I hope that helps you understand how the graph does not depict how many
users elected to use systemd as their init system.

Best regards,
--
Cameron Norman

[Marc Haber]

Post by Marco d'Itri

Post by Steve Langasek
Please stop using graphs showing how various teams have forced systemd onto
users' systems as if it is somehow a democratic endorsement of the outcome.

I am not sure about how the concept of democracy applies to this, but
the graph clearly shows that nobody is being forced to do anything and
indeed about 4000 users choose to install systemd-shim and to not use
systemd.

I would like to know how many of those 4000 users had to install
systemd-shim to get vital functionality back that

- originated from a Debianism in sysvinit
- was - rightfully - not on the agenda of systemd since it was a
Debianism
- is still being ignored by the people reponsible to _integrate_
systemd with Debian.

One example of such a Debianism is the support of the keyscript=
option in /etc/crypttab that is not available on Debian systems
running systemd with no viable alternatives available.

Greetings
Marc

[Philipp Kern]

Post by Marc Haber
One example of such a Debianism is the support of the keyscript=
option in /etc/crypttab that is not available on Debian systems
running systemd with no viable alternatives available.

And again, what you are refering to is keyscript= for non-root volumes.
It works just fine for / being unlocked through initramfs-tools.

I.e. it works fine in the multiple disks in a machine with full-disk
encryption case. It does not work where systemd is involved, i.e.
bringing them up after the root filesystem has been mounted.

Kind regards
Philipp Kern

[Marc Haber]

Post by Philipp Kern

Post by Marc Haber
One example of such a Debianism is the support of the keyscript=
option in /etc/crypttab that is not available on Debian systems
running systemd with no viable alternatives available.

And again, what you are refering to is keyscript= for non-root volumes.
It works just fine for / being unlocked through initramfs-tools.
I.e. it works fine in the multiple disks in a machine with full-disk
encryption case. It does not work where systemd is involved, i.e.
bringing them up after the root filesystem has been mounted.

I cannot confirm this, but will investigate in due time.

Greetings
Marc

[Svante Signell]

Post by Steven Chamberlain
rejected. I hope a Blend would be a more constructive approach. I'm
thinking sysvinit would be the easiest 'flavour' to implement for

Actually, I think it’s the hardest one.
All others will be task selections run after debootstrap.
Changing the init system in d-i would be done by passing
--include=sysvinit-core --exclude=systemd-sysv and things
like that (the exact set to be determined by people in
the know).
Oh, and afterwards ensure systemd is not re-added. The
prevent-systemd-* package set can do this in three steps,
although I don’t currently see even prevent-systemd-running
(Conflicts mostly with systemd-sysv) being accepted, so
you’d have to pregenerate some APT pinning configuration
and hope it holds.

It would be nice to have the same init system:sysv-core, as well as the
same default desktop:mate-desktop-environment (including accessibility
enhancements), for all arches: Linux, kFreeBSD and Hurd :-) If possible,
this could be an option in the advanced menu of the installer.