RFC: OpenRC as Init System for Debian

[Patrick Lauer]

Greetings,

in the last months there have been many discussions about init systems,
especially systemd. The current state seems to make no one really happy
- the current debian init system is a bit minimal and doesn't even do
stateful services in an elegant way (e.g. /etc/init.d/apache2 start;
/etc/init.d/apache2 start). On the other hand systemd is just Not The
Unix Way, it consolidates everything into one huge process and forces
some imppossible dependencies (dbus? udev? on my server?! and you expect
a linux 3.0+ kernel? waaah!). But "everyone else" is moving to systemd,
so where does that leave us? (One might notice that "everyone else" is
just Fedora/RHEL at the moment, with (open)SuSE tagging along, and most
others still not committed to a migration yet)

I'd like to ask you to evaluate OpenRC as candidate to replace the "old"
have-always-been-there sysvinit/insserv init scripts in Debian.

While Gentoo is by far the largest user it's definitely not the only one
- there are the direct derivatives (Sabayon, pentoo, funtoo,
sysrescuecd, tinhat, ...) and some "foreign" users (Alpine, a debian
derivative, uses OpenRC)

What we offer you is a modern, slim, userfriendly init system with
minimal dependencies. All you need is a C99 compiler and a posix sh!
The list of features is long and tedious (see
http://wiki.gentoo.org/wiki/OpenRC ), but the critical bits are:

* portable - we have it running on Linux, *BSD, and there's no reason
why it should fail on other unixoid platforms
* dependency-based init scripts - no need to manually figure out the
startup order, something like "before apache, after logger" is all you
need to specify
* small footprint - 10k LoC C99, ~3k LoC Posix SH out of the box (plus
your own init scripts, of course)
* friendly responsive upstream (let's figure out how we can cooperate, eh?)
* boring - deterministic reproducable bootup, including interactive mode
and verbose debug output

For a long time we haven't done any active advertising, but OpenRC is
now about 5 years old, and it is a drop-in replacement for our previous
"baselayout" init system (which was started over a decade ago). We don't
try to take over the world, we just create the best solution for our
needs. And those go all the way from embedded systems (where you can use
busybox for all the shell tools) to servers (minimal deps! No mandatory
udev or dbus!) and desktops (including optional splash screen eyecandy
and whatever makes you happy).

There's pretty good support for advanced usage like SELinux, built-in
support for ulimit and cgroups to do per-service resource limits, and it
even comes with a friendly license (although some might say that a
2-clause BSD license it too friendly and promiscuous). And as a random
bonus feature you get stupid-fast bootup - We've seen <5sec from
bootloader handover to login prompt (depending on hardware and amount of
services started, of course) and <5sec for rebooting a kvm guest.

Should you decide to switch (or just evaluate if switching is possible /
makes sense) you'll get full support from us in migrating init scripts
and figuring out all the nontrivial changes. Just visit us on IRC (
#openrc on irc.freenode.net), send us a mail ( ***@gentoo.org ) or
meet us for a beer or two.

Thanks for your consideration,

Patrick Lauer

Gentoo Developer, OpenRC co-maintainer

[Arto Jantunen]

Post by Patrick Lauer
in the last months there have been many discussions about init systems,
especially systemd. The current state seems to make no one really happy
- the current debian init system is a bit minimal and doesn't even do
stateful services in an elegant way (e.g. /etc/init.d/apache2 start;
/etc/init.d/apache2 start). On the other hand systemd is just Not The
Unix Way, it consolidates everything into one huge process and forces
some imppossible dependencies (dbus? udev? on my server?! and you expect
a linux 3.0+ kernel? waaah!). But "everyone else" is moving to systemd,
so where does that leave us? (One might notice that "everyone else" is
just Fedora/RHEL at the moment, with (open)SuSE tagging along, and most
others still not committed to a migration yet)
I'd like to ask you to evaluate OpenRC as candidate to replace the "old"
have-always-been-there sysvinit/insserv init scripts in Debian.

Based on this text it seems to me that OpenRC doesn't do anything that
our current init wouldn't do (we already have dependencies and
concurrent startup), and also that it wouldn't solve the problem upstart
and systemd were created to solve. I might be wrong here since I don't
know OpenRC, so correct me if I'm missing something.

It seems to me that many of the conversations about init systems have
been missing the point quite badly as well, so it might be that this
isn't obvious.

To me the point is clearly reliable bootup, not speed or dependencies
themselves (the dependencies are required for implementing reliable
bootup, and the speed is produced as a side effect of correctness).

Reliability in the case of modern kernels and modern hardware means
event based, not static. The hardware in a modern computer comes and
goes as it pleases (usb devices being the worst example, but scanning
for pci or sata busses and loading drivers isn't exactly instant in all
cases either), and the kernel has little choice in the matter. It can
either sleep until "everything is surely detected by now" before passing
control to userspace, or pass control and the problem along (by
providing event notification when the device set changes). The kernel
made its choice about this years ago, and we have been living on
borrowed time and kludges since then.

[Patrick Lauer]

On 04/25/12 21:40, Arto Jantunen wrote:
[snip]

Post by Arto Jantunen

Post by Patrick Lauer
I'd like to ask you to evaluate OpenRC as candidate to replace the "old"
have-always-been-there sysvinit/insserv init scripts in Debian.

Based on this text it seems to me that OpenRC doesn't do anything that
our current init wouldn't do (we already have dependencies and
concurrent startup),

* stateful init scripts (e.g. /etc/init.d/apache2 start
-> * WARNING: apache2 has already been started)

* nice management tools (rc-status shows what init scripts are in the
current runlevel and their current state)

And many small features that just make life a bit easier like named
runlevels (so it's "single" instead of "1")

Post by Arto Jantunen
and also that it wouldn't solve the problem upstart
and systemd were created to solve. I might be wrong here since I don't
know OpenRC, so correct me if I'm missing something.

Both upstart and systemd suffer from NIH and (imo) fail to be simple and
reliable. But you are right, OpenRC is not revolutionary, it's more a
consequent evolution that happened as we were slowly fixing all the
little bugs that annoyed us.

Post by Arto Jantunen
It seems to me that many of the conversations about init systems have
been missing the point quite badly as well, so it might be that this
isn't obvious.
To me the point is clearly reliable bootup, not speed or dependencies
themselves (the dependencies are required for implementing reliable
bootup, and the speed is produced as a side effect of correctness).

In my experience OpenRC has the most reliable and deterministic bootup,
and it makes it easy to figure out your current state (is apache still
running? Should it be running?)

Performance and all that is just a bonus for me, always correct is more
important than fast :)

Post by Arto Jantunen
Reliability in the case of modern kernels and modern hardware means
event based, not static. The hardware in a modern computer comes and
goes as it pleases (usb devices being the worst example, but scanning
for pci or sata busses and loading drivers isn't exactly instant in all
cases either), and the kernel has little choice in the matter. It can
either sleep until "everything is surely detected by now" before passing
control to userspace, or pass control and the problem along (by
providing event notification when the device set changes). The kernel
made its choice about this years ago, and we have been living on
borrowed time and kludges since then.

I mildly disagree there. The init system doesn't need to know about such
things, it only provides the actions. The device manager (what used to
be udev+hal, then was udev/gudev and is now systemd) should handle the
policy. So - connecting a usb wlan card triggers a kernel event, which
udev processes, and udev then decides from its rules what action to take
- say /etc/init.d/net.wlan0 start
(Although there is a considerable overlap between rules and actions)

For me there's no reason why udev / mdev can't stay standalone,
integrating it into the startup scripts doesn't feel right.

Have a nice day,

Patrick Lauer

[Igor Pashev]

I wonder no one mention Solaris SMF :-)

[Gergely Nagy]

Post by Igor Pashev
I wonder no one mention Solaris SMF :-)

Does a free port of that thing exist, which we could use?

[Holger Levsen]

Hi,

as a very first step I suggest to get OpenRC packaged for Debian. Until then,
your suggestion is a bit like suggesting to use the hurd as the default kernel
;-)


cheers,
Holger

[Thomas Goirand]

Post by Holger Levsen
Hi,
as a very first step I suggest to get OpenRC packaged for Debian. Until then,
your suggestion is a bit like suggesting to use the hurd as the default kernel
;-)
cheers,
Holger

Patric is in Shanghai, like me, I can work with him on that.
I might see him tonight at the Shanghai LUG "hacking Thursday"! :)

Thomas

[Roger Leigh]

Post by Patrick Lauer
I'd like to ask you to evaluate OpenRC as candidate to replace the "old"
have-always-been-there sysvinit/insserv init scripts in Debian.

While as others have mentioned that ideally a more dynamic init
system such as systemd or upstart is where I think the general
consensus is (we all know that sysvinit/insserv is flawed in many
ways, even if we can't agree on what should replace it), there is
always the possibility of having OpenRC as a sysvinit alternative
in the interim, or potentially as a systemd/upstart alternative
longer term.

Initially, we'd want to package it and make sure that it works
with our existing init scripts, before it could be considered as
the default. (Obviously we can't make any promises about that;
we already have a number of alternative inits, and OpenRC would be
one of several.)

I think the key requirement is that it can function as a drop-in
replacement for sysvinit/insserv. Are there any important
differences? Does it treat LSB dependencies the same as insserv?
How about old scripts lacking dependency info? Are the dependencies
computed dynamically or generated? (insserv hooks into update-rc.d)


Regards,
Roger

[Bernd Zeimetz]

Post by Roger Leigh

Post by Patrick Lauer
I'd like to ask you to evaluate OpenRC as candidate to replace the "old"
have-always-been-there sysvinit/insserv init scripts in Debian.

While as others have mentioned that ideally a more dynamic init
system such as systemd or upstart is where I think the general
consensus is (we all know that sysvinit/insserv is flawed in many
ways, even if we can't agree on what should replace it), there is
always the possibility of having OpenRC as a sysvinit alternative
in the interim, or potentially as a systemd/upstart alternative
longer term.
Initially, we'd want to package it and make sure that it works

------------^^^^^
Does that mean you are working on it already? ;) So far I think using
OpenRC is the first sane idea in this longish discussion, and while I
won;t have the time to maintain it I would be happy to help with the
initial packaging and testing.

Post by Roger Leigh
with our existing init scripts, before it could be considered as
the default. (Obviously we can't make any promises about that;
we already have a number of alternative inits, and OpenRC would be
one of several.)
I think the key requirement is that it can function as a drop-in
replacement for sysvinit/insserv. Are there any important
differences? Does it treat LSB dependencies the same as insserv?
How about old scripts lacking dependency info? Are the dependencies
computed dynamically or generated? (insserv hooks into update-rc.d)
Regards,
Roger

[Roger Leigh]

Post by Bernd Zeimetz

Post by Roger Leigh

Post by Patrick Lauer
I'd like to ask you to evaluate OpenRC as candidate to replace the "old"
have-always-been-there sysvinit/insserv init scripts in Debian.

While as others have mentioned that ideally a more dynamic init
system such as systemd or upstart is where I think the general
consensus is (we all know that sysvinit/insserv is flawed in many
ways, even if we can't agree on what should replace it), there is
always the possibility of having OpenRC as a sysvinit alternative
in the interim, or potentially as a systemd/upstart alternative
longer term.
Initially, we'd want to package it and make sure that it works

------------^^^^^
Does that mean you are working on it already? ;) So far I think using
OpenRC is the first sane idea in this longish discussion, and while I
won;t have the time to maintain it I would be happy to help with the
initial packaging and testing.

Not yet, I hadn't looked at it at all until mentioned on this thread.
But I am exploring it in a bit more detail and discussing it with
the OpenRC developers. It's definitely worth considering. It has
some significant advantages over startpar/insserv. In the longer
term, if systemd/upstart are an inevitability, whether it's worth
doing is perhaps moot.

- startpar computes the inter-script dependencies from the LSB info
when update-rc.d is run. openrc does it dynamically, without there
being a static .depend file. It's probably more robust in
consequence; it can't get out of date or break if there are manual
changes
- the scripts are much cleaner. All the common stuff found in our
scripts is removed. So you just provide functions for start and
stop actions etc. No need for all the boilerplate. The dependency
info is also provided this way as well, so no need to parse comments.
- knows whether services are running or not
- supports cgroups like systemd
- supports kFreeBSD (unlike systemd, the cgroups and other)
- (could potentially support Hurd)

OpenRC doesn't currently parse LSB headers; it would definitely need to
be able to do this before we could adopt it.
systemd (I think) currently understands LSB headers; it would also need
to be able to process OpenRC dependencies as well, AFAIK.

I'm going to investigate it in more detail on a running Gentoo system
and learn a bit more about it before doing anything. If anyone fancies
doing the packaging, I'll be happy to join in. I'll probably be able
to provide a better overview once I know a bit more.


Regards,
Roger

[Bernd Zeimetz]

On 04/26/2012 02:42 PM, Roger Leigh wrote:
[..]

Post by Roger Leigh
OpenRC doesn't currently parse LSB headers; it would definitely need to
be able to do this before we could adopt it.

What does it do instead? Getting rid of LSB headers in favour of
something sane might be a good idea (yeah, I know that there would be a
painful transition...).

Post by Roger Leigh
systemd (I think) currently understands LSB headers; it would also need
to be able to process OpenRC dependencies as well, AFAIK.
I'm going to investigate it in more detail on a running Gentoo system
and learn a bit more about it before doing anything. If anyone fancies
doing the packaging, I'll be happy to join in. I'll probably be able
to provide a better overview once I know a bit more.
Regards,
Roger

[Thomas Goirand]

Post by Roger Leigh
If anyone fancies
doing the packaging, I'll be happy to join in. I'll probably be able
to provide a better overview once I know a bit more.
Regards,
Roger

As I wrote already, Patrick lives in Shanghai just like me. What happened
is that I've discussed with him about the -devel thread, and explained to
him what kind of issues we are facing, with systemd being difficult to
port for hurd / kFreeBSD, the huge redundancy we have currently in our
init.d scripts, issues with the upstart contributor agreements, etc.
Then he started this thread (maybe he has read our other threads
about init alternatives, I don't know...).

I'd be very happy to work on the packaging of OpenRC, and work with
Patrick on anything we would need for a better integration in Debian.
I always work with people remotely, it'd be great if this was a good
opportunity to change this for once.

I don't know much about OpenRC apart from what Patrick told me,
but I'd be happy to discover it. Maybe I can start packaging with
Patrick together, and with you as well.

I've read others writing that they don't like the LSB headers. I'd like
to know why. What's wrong with it? I find ok-ish. Sure perfectible,
sure the syntax is a bit stupid and verbose for no reasons, but that's
not *that* bad. So, could you tell why you think it's bad? (this of
course isn't aimed at Roger specifically, but to everyone)

Next: if the LSB headers are bad, what are our options to move
away from them? Should we do some kind of tools to convert them
to a better, simpler format? How does it work with systemd for
example? I've just read about .depend files, how are they handled?

I agree that best would be if OpenRC was a simple drop-in replacement
for insserv, and if it supported what we currently have *PLUS* some
new features (which have already been discussed during huge threads,
I don't feel like enumerating them again...). If it doesn't, then maybe
I can beat-up^Wmotivate Patric to work toward that goal of
supporting our already existing infrastructure.

I'm not sure where all this will lead me/Debian, but I think this is
worth a try. I'll try to catch-up with Patrick and talk with him about
how we can start doing this. Maybe we can also have a round table
about this during Debconf12...

Cheers,

Zigo

[Roger Leigh]

Post by Thomas Goirand

Post by Roger Leigh
If anyone fancies
doing the packaging, I'll be happy to join in. I'll probably be able
to provide a better overview once I know a bit more.

I don't know much about OpenRC apart from what Patrick told me,
but I'd be happy to discover it. Maybe I can start packaging with
Patrick together, and with you as well.

That sounds great. I'm equally in the dark regarding OpenRC, though
I've checked the git repo out and had a chat on IRC with some of the
developers. My initial impressions are that it adds some very nice
features which are lacking in our current default sysvinit setup,
while not going quite as far as systemd/upstart. Certainly a very
nice upgrade to what we currently have, while not being as radical a
change as the other alternatives. Other than replacing the /etc/rc?.d
symlink farms with /etc/runlevels/name (and most of us really don't
care about runlevels directly), it's pretty much identical from the
user's POV.

I've taken the liberty of creating a repo on collab-maint for Debian
packaging. git://git.debian.org/git/collab-maint/openrc.git
It's currently just branched from the current upstream repo with
no changes.

Post by Thomas Goirand
I've read others writing that they don't like the LSB headers. I'd like
to know why. What's wrong with it? I find ok-ish. Sure perfectible,
sure the syntax is a bit stupid and verbose for no reasons, but that's
not *that* bad. So, could you tell why you think it's bad? (this of
course isn't aimed at Roger specifically, but to everyone)

Two issues that come to mind
- it's not permitted for a package to declare that it provides a
virtual service, e.g. $cron. This is actually in the LSB spec.
OpenRC does allow this. There are several bugs about this.
- it's just a block of text inside a shell script comment. Not the
nicest thing to parse. In comparison systemd is entirely
declarative. OpenRC is sort-of declarative inside a shell function,
but is actually part of a script so you can define them
programatically as well from what I can tell, which would mean it
might be possible to conditionally depend on things.

depend()
{
need localmount
keyword -jail -openvz -prefix -vserver -lxc
}

depend()
{
need localmount
after bootmisc
provide net
keyword -jail -vserver
}

Post by Thomas Goirand
Next: if the LSB headers are bad, what are our options to move
away from them? Should we do some kind of tools to convert them
to a better, simpler format? How does it work with systemd for
example? I've just read about .depend files, how are they handled?

The .depend files are an internal implementation detail of startpar
and insserv. insserv generates them from the LSB headers, while
startpar uses them to parallelise startup. If you take a look, you'll
see that it's basically Makefile-style dependencies.

systemd unit files are purely declarative descriptions of services.
It uses socket-based activation to defer starting services, similar
in concept to inetd I guess, but encompassing much much more. So
a service will get started when something tries to connect to it,
which will block until it's available. It's a really nice concept.
I've not figured out exactly how the OpenRC dependencies work, or if
it's possible to dump them by running the script. I've had a small
look, but not had enough time to familiarise myself with it all yet.

Post by Thomas Goirand
I agree that best would be if OpenRC was a simple drop-in replacement
for insserv, and if it supported what we currently have *PLUS* some
new features (which have already been discussed during huge threads,
I don't feel like enumerating them again...). If it doesn't, then maybe
I can beat-up^Wmotivate Patric to work toward that goal of
supporting our already existing infrastructure.
I'm not sure where all this will lead me/Debian, but I think this is
worth a try. I'll try to catch-up with Patrick and talk with him about
how we can start doing this. Maybe we can also have a round table
about this during Debconf12...

I think it's definitely worth exploring. From our chatting on IRC, I
think the following came out of it:

- We need LSB dependency support in OpenRC in order to support all the
init scripts in Debian which utilise them. Definitely required in
order to make it possible to evaluate OpenRC without converting the
entire distribution immediately.

- Converting all our core initscripts probably isn't a massive task.
It can probably be done inside a weekend. There's undoubtedly a
large amount of overlap with the OpenRC scripts, which would need
removing/replacing where appropriate.

- Given that runlevels have names rather than numbers, we would need
to look into how update-rc.d interacts with OpenRC. Conversion of
/etc/rc?.d to /etc/runlevels (and in reverse) also needs
investigation. For update-rc.d we could probably map the standard
0/1/2/6 numbers to the OpenRC boot/single/default/shutdown names.

- Debian's support of multiple init systems makes migration to and
from OpenRC difficult. At the present, sysvinit/initscripts is the
default, and alternatives may be installed to replace them in whole
or in part:
- file-rc
- systemd
- upstart
upstart is the most difficult to deal with. Unlike systemd, which
allows both units and init scripts to be provided together, upstart
requires (if I understand correctly) either an init script or an
upstart job, but not both. But all support LSB init scripts as a
basic part of their functionality. They key point is that LSB
initscripts are the lowest common denominator, and changing init
systems generally involves going via sysvinit as the intermediate
step.

Were we to replace sysvinit/startpar/insserv with OpenRC, it would
replace LSB initscripts as the lowest common denominator with
OpenRC initscripts (while also supporting LSB initscripts). While
this change in itself would be fairly simple, in order to continue
to permit other init systems to replace it, it would require some
degree of support for OpenRC scripts in systemd, upstart etc. This
probably amounts to teaching systemd how to extract the necessary
dependency information as it presumably already does for the LSB
headers, and the equivalent process for the others. They might
also need to provide a replacement /sbin/runscript.


So to get started with OpenRC, we need LSB header support. Everything
else can come later, should we want to make it the default.


Regards,
Roger

[Tollef Fog Heen]

]] Roger Leigh

Post by Roger Leigh
Two issues that come to mind
- it's not permitted for a package to declare that it provides a
virtual service, e.g. $cron. This is actually in the LSB spec.
OpenRC does allow this. There are several bugs about this.

It's not permitted _for LSB applications_. None of the packages shipped
in Debian are LSB applications and we're completely free to Provide:
$cron if we so desire, and I think not doing that in the init script
would be a bad idea. If implementations don't support that, they should
just be fixed, IMO.

[Roger Leigh]

Post by Roger Leigh
I'm going to investigate it in more detail on a running Gentoo system
and learn a bit more about it before doing anything. If anyone fancies
doing the packaging, I'll be happy to join in. I'll probably be able
to provide a better overview once I know a bit more.

Just to provide a bit more context for this discussion. After
learning a bit more about how OpenRC works, thanks to their
assistance on IRC:

- OpenRC is a relacement for sysv-rc/insserv/startpar
- It still depends on sysvinit, though only for the initial
inittab runlevel actions.
- It uses its own dependency system rather than LSB. In some
ways, it's nicer (starting a script manually will also start
the required deps, something LSB scripts can not do), and most
of the LSB deps will map to OpenRC deps (not sure about all the
(X- variants yet)
- It looks like it will be possible to get OpenRC to run LSB
scripts and cope with LSB dependencies, which would let us
evaluate it in Debian.

So from the POV of the wider systemd/upstart debate, it's not
going to particularly affect that. I think this could be
viewed as a potentially good upgrade from insserv/startpar.


Regards,
Roger

[Marco d'Itri]

Post by Patrick Lauer
in the last months there have been many discussions about init systems,
especially systemd. The current state seems to make no one really happy

Not true. systemd and upstart do not make /everybody/ happy, but nothing
does.

Post by Patrick Lauer
I'd like to ask you to evaluate OpenRC as candidate to replace the "old"
have-always-been-there sysvinit/insserv init scripts in Debian.

What we need is an event-driven init system, anything else will just
make us waste more time.

Post by Patrick Lauer
What we offer you is a modern, slim, userfriendly init system with

Sorry, no. upstart, systemd or the Apple thing are modern init systems,
this one is not.
But I agree that it would have been nice 5 years ago.

[Svante Signell]

...

Post by Marco d'Itri

Post by Patrick Lauer
I'd like to ask you to evaluate OpenRC as candidate to replace the "old"
have-always-been-there sysvinit/insserv init scripts in Debian.

What we need is an event-driven init system, anything else will just
make us waste more time.

And the _technical_ motivation for that is?? Please give a link or explain!

Post by Marco d'Itri

Post by Patrick Lauer
What we offer you is a modern, slim, userfriendly init system with

Sorry, no. upstart, systemd or the Apple thing are modern init systems,
this one is not
But I agree that it would have been nice 5 years ago.

See above!

[Chow Loong Jin]

Post by Svante Signell
...

Post by Marco d'Itri

Post by Patrick Lauer
I'd like to ask you to evaluate OpenRC as candidate to replace the "old"
have-always-been-there sysvinit/insserv init scripts in Debian.

What we need is an event-driven init system, anything else will just
make us waste more time.

And the _technical_ motivation for that is?? Please give a link or explain!

Post by Marco d'Itri

Post by Patrick Lauer
What we offer you is a modern, slim, userfriendly init system with

Sorry, no. upstart, systemd or the Apple thing are modern init systems,
this one is not
But I agree that it would have been nice 5 years ago.

See above!
Reliability in the case of modern kernels and modern hardware means
event based, not static. The hardware in a modern computer comes and
goes as it pleases (usb devices being the worst example, but scanning
for pci or sata busses and loading drivers isn't exactly instant in all
cases either), and the kernel has little choice in the matter. It can
either sleep until "everything is surely detected by now" before passing
control to userspace, or pass control and the problem along (by
providing event notification when the device set changes). The kernel
made its choice about this years ago, and we have been living on
borrowed time and kludges since then.

[Eray Aslan]

Post by Arto Jantunen
Reliability in the case of modern kernels and modern hardware means
event based, not static. The hardware in a modern computer comes and
goes as it pleases (usb devices being the worst example, but scanning

That's the thing. Hardware do not come and go as it pleases on my
servers and I do not want anything happening when someone inserts a usb
device. It's nice on my laptop but not on my servers.

[Arto Jantunen]

Post by Eray Aslan

Post by Arto Jantunen
Reliability in the case of modern kernels and modern hardware means
event based, not static. The hardware in a modern computer comes and
goes as it pleases (usb devices being the worst example, but scanning

That's the thing. Hardware do not come and go as it pleases on my
servers and I do not want anything happening when someone inserts a usb
device. It's nice on my laptop but not on my servers.

So you have absolute control on which device gets detected by the kernel
at which exact moment? That's a cool trick indeed, you really need to
teach me how to do that.

Unless you have radically modified things from the way the kernel works
by default, a lot of things already happen on your servers when a usb
device is inserted (the kernel notices the device and loads a driver,
udev (if it's running and not modified) creates the relevant device
nodes, etc).

I agree that automatically mounting usb sticks or such on servers would
be more than silly, and haven't suggested that (neither have the upstart
and systemd upstream developers, as far as I'm aware).

[Bernd Zeimetz]

Post by Arto Jantunen

Post by Eray Aslan

Post by Arto Jantunen
Reliability in the case of modern kernels and modern hardware means
event based, not static. The hardware in a modern computer comes and
goes as it pleases (usb devices being the worst example, but scanning

That's the thing. Hardware do not come and go as it pleases on my
servers and I do not want anything happening when someone inserts a usb
device. It's nice on my laptop but not on my servers.

So you have absolute control on which device gets detected by the kernel
at which exact moment? That's a cool trick indeed, you really need to
teach me how to do that.
Unless you have radically modified things from the way the kernel works
by default, a lot of things already happen on your servers when a usb
device is inserted (the kernel notices the device and loads a driver,
udev (if it's running and not modified) creates the relevant device
nodes, etc).

And udev does this jus fine, I don't need systemd or whatever else on
top of that.

Post by Arto Jantunen
I agree that automatically mounting usb sticks or such on servers would
be more than silly, and haven't suggested that (neither have the upstart
and systemd upstream developers, as far as I'm aware).

[Josselin Mouette]

Post by Bernd Zeimetz

Post by Arto Jantunen
Unless you have radically modified things from the way the kernel works
by default, a lot of things already happen on your servers when a usb
device is inserted (the kernel notices the device and loads a driver,
udev (if it's running and not modified) creates the relevant device
nodes, etc).

And udev does this jus fine, I don't need systemd or whatever else on
top of that.

So you want to replace init scripts by udev scripts? This might work for
part of the required functionality, but so far it looks like vaporware.

[Svante Signell]

Post by Josselin Mouette

Post by Bernd Zeimetz

Post by Arto Jantunen
Unless you have radically modified things from the way the kernel works
by default, a lot of things already happen on your servers when a usb
device is inserted (the kernel notices the device and loads a driver,
udev (if it's running and not modified) creates the relevant device
nodes, etc).

And udev does this jus fine, I don't need systemd or whatever else on
top of that.

So you want to replace init scripts by udev scripts? This might work for
part of the required functionality, but so far it looks like vaporware.

Init is about the boot of the computer, right? Who is stupid enough to
put in a usb stick _during_ the boot? We need to separate boot from
adding/removing peripheral devices!

- Either the usb is not there during the boot and when inserted can be
detected, by whatever software. Or you could teach the kernel about it's
presence, like adding an fstab entry.

- Alternately, the usb stick is inserted before the boot, and either it
does not necessarily have to be mounted, or you know it has to be
mounted, ant that can be prepared for in advance, e.g. by adding an
fstab entry. With this reasoning there is _no_ need for for an event
driven boot system, a dependency-based one is OK.

Additionally there is _no_ need to being able to add/remove peripheral
devices without the admin/user being aware of that, and for servers
nothing should happen as mentioned before. In summary, in practice,
there is real need for this M$ "plug and play" more known as "plug and
pray" or "plug and pay",

[Jon Dowland]

Post by Svante Signell
Init is about the boot of the computer, right? Who is stupid enough to
put in a usb stick _during_ the boot? We need to separate boot from
adding/removing peripheral devices!

I've no idea why that would be stupid.

If I were booting a computer and intended to use some USB peripherals, I
may very well do the plugging prior to boot finishing. Whilst I go off and
make a cup of tea, because the boot STILL takes too long.

What sounds stupid to me is having a brittle system that can actually be
disrupted by plugging in a USB stick whilst it's booting!

Note that I don't necessarily need the hotplugged USB stick to be
available *to the system* during boot - perhaps the plumbing that mounts
it hasn't been started up yet. (And hopefully that GDM3 bug that mounted
disks as the Debian-gdm3 has gone now.)

[Svante Signell]

Post by Jon Dowland

Post by Svante Signell
Init is about the boot of the computer, right? Who is stupid enough to
put in a usb stick _during_ the boot? We need to separate boot from
adding/removing peripheral devices!

I've no idea why that would be stupid.
If I were booting a computer and intended to use some USB peripherals, I
may very well do the plugging prior to boot finishing. Whilst I go off and
make a cup of tea, because the boot STILL takes too long.

If it takes that long time you might consider coreboot!

Post by Jon Dowland
What sounds stupid to me is having a brittle system that can actually be
disrupted by plugging in a USB stick whilst it's booting!

They shouldn't, inserting an USB during boot should not result in an
action whatsoever.

Post by Jon Dowland
Note that I don't necessarily need the hotplugged USB stick to be
available *to the system* during boot - perhaps the plumbing that mounts
it hasn't been started up yet. (And hopefully that GDM3 bug that mounted
disks as the Debian-gdm3 has gone now.)

Dunno about gdm3 bug, sorry.

[Russell Coker]

Post by Jon Dowland

Post by Svante Signell
Init is about the boot of the computer, right? Who is stupid enough to
put in a usb stick _during_ the boot? We need to separate boot from
adding/removing peripheral devices!

I've no idea why that would be stupid.
If I were booting a computer and intended to use some USB peripherals, I
may very well do the plugging prior to boot finishing. Whilst I go off and
make a cup of tea, because the boot STILL takes too long.

Yes. It's not THAT uncommon that I'll boot a laptop for the sole purpose of
reading data from a USB stick and I expect that others do the same.

Also there's the possibility of booting a laptop/netbook from a USB stick and
then using an encrypted root device. This prevents an attacker who has
temporary access to the system from subverting the boot process on disk, the
attacker could still subvert the BIOS but that's more difficult. In the case
of such things you would have the USB device seen early in the boot and then
removed during the boot process.

http://etbe.coker.com.au/2012/03/11/usb-flash-storage/
http://etbe.coker.com.au/2012/04/08/flash-storage-update/

Anyone who reads Planet Debian would have seen the above two posts I wrote
about using USB flash devices for all storage in a system. While that is an
unusual use of a system it's really nice if we can make things just work so
that the user gets a full range of choices about how their system works.
While I don't expect that the kernel and udev developers and package
maintainers (who are really very busy) would go to extra effort to make my
particular corner case work I'm sure that they are quite happy that their good
work results in all manner of unusual corner cases just working for various
people.

Post by Jon Dowland
What sounds stupid to me is having a brittle system that can actually be
disrupted by plugging in a USB stick whilst it's booting!

Every version of Debian is released with some bugs, it's the way that software
development goes. If the worst bug was that plugging a USB stick at the wrong
time could disrupt the boot then I think that most people would consider it as
ready for a release.

The real problem is when people start claiming that such things aren't bugs.

As an aside, my monitor has some sort of SD card reader built in. I've never
used it but it registers as a SCSI device. This means that the order of
switching on my monitor and inserting a USB stick affects what the device name
will be. With a static /etc/fstab this doesn't work too well for me.
Hopefully I will find a better solution.

[Thomas Goirand]

Post by Russell Coker
Every version of Debian is released with some bugs, it's the way that software
development goes. If the worst bug was that plugging a USB stick at the wrong
time could disrupt the boot then I think that most people would consider it as
ready for a release.

Especially considering that we can fix stuff in Stable
if the release team agrees...

Thomas

[Bernd Zeimetz]

Post by Thomas Goirand

Post by Russell Coker
Every version of Debian is released with some bugs, it's the way that software
development goes. If the worst bug was that plugging a USB stick at the wrong
time could disrupt the boot then I think that most people would consider it as
ready for a release.

Especially considering that we can fix stuff in Stable
if the release team agrees...

Which bug number is that?

[Josselin Mouette]

Post by Svante Signell
Init is about the boot of the computer, right? Who is stupid enough to
put in a usb stick _during_ the boot? We need to separate boot from
adding/removing peripheral devices!

Yes of course, because event-driven init systems have *always* been
*only* about mounting USB devices. Mounting an USB device is such a
complicated action, one wonders how it can even work.

[Svante Signell]

Post by Josselin Mouette

Post by Svante Signell
Init is about the boot of the computer, right? Who is stupid enough to
put in a usb stick _during_ the boot? We need to separate boot from
adding/removing peripheral devices!

Yes of course, because event-driven init systems have *always* been
*only* about mounting USB devices.

Then explain the _real_ reasons for having an event driven boot system!
Finding new hardware for example can be related to software like hwdata.
And why is udev classified as important, what's the use of that on
servers?

Post by Josselin Mouette
Mounting an USB device is such a
complicated action, one wonders how it can even work.

Yes, it seems like wonders happens, how can it be?

[Josselin Mouette]

Post by Svante Signell

Post by Josselin Mouette
Yes of course, because event-driven init systems have *always* been
*only* about mounting USB devices.

Then explain the _real_ reasons for having an event driven boot system!

BECAUSE THE LINUX KERNEL IS EVENT DRIVEN.
Full stop.
End of story.
Bye bye.

This must have been explained HUNDREDS of times in the endless threads
full of stupid messages from stupid dumbasses who don’t understand a
thing about init systems but don’t want their precious, idiotic, buggy
init scripts to go away.

Post by Svante Signell
Finding new hardware for example can be related to software like hwdata.
And why is udev classified as important, what's the use of that on
servers?

Because Linux, in its current architecture, won’t work correctly without
it.

[Martin Wuertele]

Post by Josselin Mouette

Post by Svante Signell

Post by Josselin Mouette
Yes of course, because event-driven init systems have *always* been
*only* about mounting USB devices.

Then explain the _real_ reasons for having an event driven boot system!

BECAUSE THE LINUX KERNEL IS EVENT DRIVEN.

That's a reason for udev/mdev, however I still fail to see why this
results in the requirement for an event based boot process.

Could you enlighten me please.

Kind regards,
Martin

[Patrick Lauer]

Post by Martin Wuertele

Post by Josselin Mouette

Post by Svante Signell

Post by Josselin Mouette
Yes of course, because event-driven init systems have *always* been
*only* about mounting USB devices.

Then explain the _real_ reasons for having an event driven boot system!

BECAUSE THE LINUX KERNEL IS EVENT DRIVEN.

That's a reason for udev/mdev, however I still fail to see why this
results in the requirement for an event based boot process.

Especially as your device manager can trigger services, so you already
have the mechanism for an event-driven system, what's missing then is
only policy ...

Post by Martin Wuertele
Could you enlighten me please.
Kind regards,
Martin

[Tollef Fog Heen]

]] Martin Wuertele

Post by Martin Wuertele

Post by Josselin Mouette

Post by Svante Signell

Post by Josselin Mouette
Yes of course, because event-driven init systems have *always* been
*only* about mounting USB devices.

Then explain the _real_ reasons for having an event driven boot system!

BECAUSE THE LINUX KERNEL IS EVENT DRIVEN.

That's a reason for udev/mdev, however I still fail to see why this
results in the requirement for an event based boot process.

A trivial example is $remote_fs isn't satisfied until /srv/somewhere is
mounted and /srv/somewhere comes off iscsi, which means it requires
networking to be up, which means network drivers loaded, etc. So the
event «network driver loaded» causes ifup to be spawned, which causes
$network to be satisfied which causes the iscsi daemons to be started
which causes mount to be called.

[Bernd Zeimetz]

Post by Tollef Fog Heen
]] Martin Wuertele

Post by Martin Wuertele

Post by Josselin Mouette

Post by Svante Signell

Post by Josselin Mouette
Yes of course, because event-driven init systems have *always* been
*only* about mounting USB devices.

Then explain the _real_ reasons for having an event driven boot system!

BECAUSE THE LINUX KERNEL IS EVENT DRIVEN.

That's a reason for udev/mdev, however I still fail to see why this
results in the requirement for an event based boot process.

A trivial example is $remote_fs isn't satisfied until /srv/somewhere is
mounted and /srv/somewhere comes off iscsi, which means it requires
networking to be up, which means network drivers loaded, etc. So the
event «network driver loaded» causes ifup to be spawned, which causes
$network to be satisfied which causes the iscsi daemons to be started
which causes mount to be called.

You actually want to start your iscsi stuff even your network is not available
right now - and you for sure don't want to stop it just because the link flaps.
iscsi is able to handle that just fine. You could even add multipath on top of
iscsi to make it even more reliable. And for all that there is no need to have
an init system which understands events. If you want to do something after your
devices appear, use udev. As traffic yo your iscsi disk will be queued in case
the connection gets lost there is also no need to find something new to handle
link up/down events. If your link is gone forever there is a broken filesystem
and some stuck IO fun anyway.

You have to find something better to convince people.
--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F

[Tollef Fog Heen]

]] Bernd Zeimetz

Post by Bernd Zeimetz
You actually want to start your iscsi stuff even your network is not
available right now - and you for sure don't want to stop it just
because the link flaps.

You need to wait for the right IP to become available so it can bind to
the right place. And why would you stop networking because the link
flaps?

Post by Bernd Zeimetz
If you want to do something after your devices appear, use udev.

udev has, intentionally, short timeouts and it should just trigger
services starting, it shouldn't run init script and such itself.

[Svante Signell]

...

Post by Josselin Mouette
This must have been explained HUNDREDS of times in the endless threads
full of stupid messages from stupid dumbasses who don’t understand a
thing about init systems but don’t want their precious, idiotic, buggy
init scripts to go away.

Please calm down, and refrain from calling people names, that is not
polite!

Post by Josselin Mouette

Post by Svante Signell
Finding new hardware for example can be related to software like hwdata.
And why is udev classified as important, what's the use of that on
servers?

Because Linux, in its current architecture, won’t work correctly without
it.

Apparently it can today ... with init scripts, which _new_ features will
be brought in for the _boot_ process. udev takes care of the events,
already today, right? More secure boot, faster boot (coreboot), better
debugging, simple ways of logging the boot massages, etc? Don't talk
about plug-and-p{r}ay, that is not interesting for _boot_: Found new
hardware, eh?

BTW: When boots is asynchronous, who is sorting the boot messages to be
readable afterwords, or is this taken care of by the now so famous tools
systemd and upstart.

Yes, next step will to install these packages and do some evaluation
comparison, nobody has done that yet, or?

[Svante Signell]

Post by Svante Signell

Post by Josselin Mouette

Post by Svante Signell
And why is udev classified as important, what's the use of that on
servers?

Because Linux, in its current architecture, won’t work correctly without
it.

To clarify: The text below is written with the assumption that udev is
used, but with init scripts used for boot.

Post by Svante Signell
Apparently it can today ... with init scripts, which _new_ features will
be brought in for the _boot_ process. udev takes care of the events,
already today, right? More secure boot, faster boot (coreboot), better
debugging, simple ways of logging the boot massages, etc? Don't talk
about plug-and-p{r}ay, that is not interesting for _boot_: Found new
hardware, eh?
BTW: When boots is asynchronous, who is sorting the boot messages to be
readable afterwords, or is this taken care of by the now so famous tools
systemd and upstart.
Yes, next step will to install these packages and do some evaluation
comparison, nobody has done that yet, or?

It might be so that Linux does not work properly without udev/mdev, what
a pity for people who don't want it.

[Vincent Bernat]

OoO Vers la fin de l'aprÚs-midi du vendredi 27 avril 2012, vers 16:29,

Post by Svante Signell
Apparently it can today ... with init scripts, which _new_ features will
be brought in for the _boot_ process. udev takes care of the events,
already today, right? More secure boot, faster boot (coreboot), better
debugging, simple ways of logging the boot massages, etc? Don't talk
about plug-and-p{r}ay, that is not interesting for _boot_: Found new
hardware, eh?

But that's the whole point : new hardware pops up while booting. See for
example a server that will need a 3G connection. The 3G connection will
be done by some classic USB key. When the USB key is detected, udev
triggers a script asking the USB key (which defaults to a mass storage
device) to switch to "modem mode". Once it becomes a modem, the 3G
connection can be initialized. Turning the USB key into a modem is
taking some time. The USB key will be "disconnected", then
"reconnected". SO, "found new hardware". ifupdown scripts were already
run and filed with "interface not found".

udev can run simple actions when a device appears but cannot run a chain
of dependencies (start the 3G connection, run some daemon that needs
Internet which in turn will trigger some client to this daemon to
run). The solution is an event-based init. We want a reliable boot.

We are in 2012 and if a non-essential daemon blocks the boot (no working
network), we have no way to get a getty to be run.

[Thomas Goirand]

Post by Vincent Bernat
We are in 2012 and if a non-essential daemon blocks the boot (no working
network), we have no way to get a getty to be run.

I agree with the rest of your post, but here, you are are
picturing a very badly written init script that doesn't have
a working failure mode! No daemon should block the boot,
even with our current system. If it does, please feel free to
file a bug.

Thomas

[Vincent Bernat]

OoO Pendant le repas du samedi 28 avril 2012, vers 19:54, Thomas Goirand

Post by Thomas Goirand

Post by Vincent Bernat
We are in 2012 and if a non-essential daemon blocks the boot (no working
network), we have no way to get a getty to be run.

I agree with the rest of your post, but here, you are are
picturing a very badly written init script that doesn't have
a working failure mode! No daemon should block the boot,
even with our current system. If it does, please feel free to
file a bug.

There is no bug. When using start-stop-daemon on a forking daemon,
start-stop-daemon waits for the process to detach which usually happens
when the process is ready to accept incoming requests. If it needs to
establish some network connections, it will not fork before.

I am not building some random theoritical situation here. It happens
with exim and cfengine for example. And it also happens when mouting
network drives. Even if you have your root ready, you won't get a getty
after long long long timeouts.

[Svante Signell]

OoO Vers la fin de l'après-midi du vendredi 27 avril 2012, vers 16:29,

Post by Svante Signell
Apparently it can today ... with init scripts, which _new_ features will
be brought in for the _boot_ process. udev takes care of the events,
already today, right? More secure boot, faster boot (coreboot), better
debugging, simple ways of logging the boot massages, etc? Don't talk
about plug-and-p{r}ay, that is not interesting for _boot_: Found new
hardware, eh?

But that's the whole point : new hardware pops up while booting. See for
example a server that will need a 3G connection. The 3G connection will
be done by some classic USB key. When the USB key is detected, udev
triggers a script asking the USB key (which defaults to a mass storage
device) to switch to "modem mode". Once it becomes a modem, the 3G
connection can be initialized. Turning the USB key into a modem is
taking some time. The USB key will be "disconnected", then
"reconnected". SO, "found new hardware". ifupdown scripts were already
run and filed with "interface not found".

Nice description, thanks. However, this is not necessarily part of the
_boot_ process!! This could/should happen _after_ the computer is up and
running, e.g. when starting X. You are not able to use your USB modem
until then anyway, and boot times should be as short as possible, not
having to wait for a dongle to connect to the wireless network. So, the
real problem is: How do you define the boot process of a computer. For
me it is when the kernel has been loaded by the boot media, memory,
graphics card, etc initialized. Some modules are needed for boot, other
modules can be loaded later. The only case I can see when you need a
network during the boot process is when booting from the network, and
for that you can predefine which modules to load.

udev can run simple actions when a device appears but cannot run a chain
of dependencies (start the 3G connection, run some daemon that needs
Internet which in turn will trigger some client to this daemon to
run). The solution is an event-based init. We want a reliable boot.

Then the functionality of udev should be extended, not dragging the
init scripts into this udev<->Linux kernel interaction. I think it
would be much better to isolate these two instead of having a third
(potentially buggy) software included.

We are in 2012 and if a non-essential daemon blocks the boot (no working
network), we have no way to get a getty to be run.

See the reply from Thomas Goirand.

[Miles Bader]

Post by Svante Signell
So, the
real problem is: How do you define the boot process of a computer. For
me it is when the kernel has been loaded by the boot media, memory,
graphics card, etc initialized. Some modules are needed for boot, other
modules can be loaded later. The only case I can see when you need a
network during the boot process is when booting from the network, and
for that you can predefine which modules to load.

Isn't mounting filesystems, which can depend on the network, part of
the boot process?

I recently had an unpleasant experience where I switched to
network-manager to make gnome-shell happy, but network-manager runs
too late in the boot process, so none of my NFS filesystems got
mounted.

I certainly wished there was a bit more proper ordering going on
then...

-miles

[Stephan Seitz]

Post by Miles Bader
Isn't mounting filesystems, which can depend on the network, part of
the boot process?

Yes, but how do you check if the network is configured and operational?
- when the link is up?
- when the IP address is configured (how do you check this with IPv6?)?
What are you doing if more than one IP address is configured for this
NIC or more than one NIC is available?
- when the switch accepts traffic on the port you are connected to?
- when the router/firewall accepts traffic from your IP address?

No event based init system will solve these problems when you have
dependencies outside the box you are booting. The local admin has to
check if all timings are right and must adjust them if they are not
fitting.

Shade and sweet water!

Stephan

[Miles Bader]

Post by Stephan Seitz

Post by Miles Bader
Isn't mounting filesystems, which can depend on the network, part of
the boot process?

Yes, but how do you check if the network is configured and operational?
- when the link is up?
- when the IP address is configured (how do you check this with
IPv6?)? What are you doing if more than one IP address is configured
for this NIC or more than one NIC is available?
- when the switch accepts traffic on the port you are connected to?
- when the router/firewall accepts traffic from your IP address?
No event based init system will solve these problems when you have
dependencies outside the box you are booting. The local admin has to
check if all timings are right and must adjust them if they are not
fitting.

Er, what? Please don't throw out silly strawmen...

-miles

[Bernd Zeimetz]

Post by Miles Bader

Post by Stephan Seitz

Post by Miles Bader
Isn't mounting filesystems, which can depend on the network, part of
the boot process?

Yes, but how do you check if the network is configured and operational?
- when the link is up?
- when the IP address is configured (how do you check this with
IPv6?)? What are you doing if more than one IP address is configured
for this NIC or more than one NIC is available?
- when the switch accepts traffic on the port you are connected to?
- when the router/firewall accepts traffic from your IP address?
No event based init system will solve these problems when you have
dependencies outside the box you are booting. The local admin has to
check if all timings are right and must adjust them if they are not
fitting.

Er, what? Please don't throw out silly strawmen...

Stephan's points are valid. Just having a link on your favourite cisco does not
mean that you are allowed to send packets anywhere yet. Getting a ipv6 address
via radvd does not mean that you are able too access your nfsv4 server (and the
other way round...). And so on.

[Miles Bader]

Post by Bernd Zeimetz

Post by Miles Bader
Er, what? Please don't throw out silly strawmen...

Stephan's points are valid. Just having a link on your favourite cisco does not
mean that you are allowed to send packets anywhere yet. Getting a ipv6 address
via radvd does not mean that you are able too access your nfsv4 server (and the
other way round...). And so on.

No, his "points" are strawmen. Nothing is perfect, and there are no
absolute guarantees of _anything_, but there are things which can
generally assumed to be work in practice (in particular anything
outside the current box).

If there are ipv6 / nfsv4 interoperability issues, that's a shame, but
it certainly shouldn't be used as an excuse to gimp the entire system,
when it may work fine for people using ipv4 and nfsv3...

That's what it sounds like Stephan is doing: "oh it can't be perfect,
so let's not even try to be good."

-miles

[Steve Langasek]

Post by Stephan Seitz

Post by Miles Bader
Isn't mounting filesystems, which can depend on the network, part of
the boot process?

Yes, but how do you check if the network is configured and operational?
- when the link is up?
- when the IP address is configured (how do you check this with
IPv6?)? What are you doing if more than one IP address is
configured for this NIC or more than one NIC is available?
- when the switch accepts traffic on the port you are connected to?
- when the router/firewall accepts traffic from your IP address?

Retransmitting your packets because the network is not yet delivering them
is an entirely different error handling scenario from rebinding because your
service was started before the system has an address (or interface). The
former is handled transparently by the protocol stack and the latter
requires every application to handle it manually - and the only way the
application can handle it is by stupid polling.

Linux is an event-based system, and we need to do event-based activation of
the software, so that we don't have to patch a hundred processes to poll for
the network to show up underneath them.

The fact that v6 addresses may come and go without generating events seen by
userspace is a deficiency with the current system; but a) it's a solvable
one, b) having reliable events for all the *other* scenarios is a huge
reliability improvement over the sysvinit status quo.

For some insight into how upstart structures its events to ensure reliable
start of network services on boot, see the Upstart Cookbook:

http://upstart.ubuntu.com/cookbook/

Post by Stephan Seitz
No event based init system will solve these problems when you have
dependencies outside the box you are booting. The local admin has to
check if all timings are right and must adjust them if they are not
fitting.

IOW, "the admin has to add a bunch of sleep's everywhere"? Pass, thanks.

[Vincent Bernat]

OoO En cette fin de matinée radieuse du dimanche 29 avril 2012, vers

Post by Svante Signell

Post by Vincent Bernat
But that's the whole point : new hardware pops up while booting. See for
example a server that will need a 3G connection. The 3G connection will
be done by some classic USB key. When the USB key is detected, udev
triggers a script asking the USB key (which defaults to a mass storage
device) to switch to "modem mode". Once it becomes a modem, the 3G
connection can be initialized. Turning the USB key into a modem is
taking some time. The USB key will be "disconnected", then
"reconnected". SO, "found new hardware". ifupdown scripts were already
run and filed with "interface not found".

Nice description, thanks. However, this is not necessarily part of the
_boot_ process!! This could/should happen _after_ the computer is up and
running, e.g. when starting X. You are not able to use your USB modem
until then anyway, and boot times should be as short as possible, not
having to wait for a dongle to connect to the wireless network.

There is no X. It is a _server_. Its only available network connection
is through this 3G usb dongle. If it does not happen on boot, it never
happens.

Post by Svante Signell

Post by Vincent Bernat
udev can run simple actions when a device appears but cannot run a chain
of dependencies (start the 3G connection, run some daemon that needs
Internet which in turn will trigger some client to this daemon to
run). The solution is an event-based init. We want a reliable boot.

Then the functionality of udev should be extended, not dragging the
init scripts into this udev<->Linux kernel interaction. I think it
would be much better to isolate these two instead of having a third
(potentially buggy) software included.

The functionality of udev should be extended to manage dependencies
between system daemons? Isn't the job of init?

[Petter Reinholdtsen]

[Svante Signell]

Post by Svante Signell
Init is about the boot of the computer, right? Who is stupid enough
to put in a usb stick _during_ the boot? We need to separate boot
from adding/removing peripheral devices!

You seem to misunderstand the problem. I will try to give a short
explanation.

The problem at hand is that adding entries to fstab do not work
reliably for USB disks. If you have the users home directories (or
any other disk that should be mounted during boot) on a USB disk, the
device might not be working when the boot get to the point in time
where it try to mount partitions. This also happen for SCSI and
network disks.

Say you want to mount a network disk during boot. This depend on the
network being configured. This in turn might depend on a DHCP reply
from a DHCP server, and to send the DHCP request the network card need
to be detected. To detect the network card, the network driver need
to be loaded, and the network card need to be found on the PCI or some
other internal bus. And with the Linux kernel today, there is no way
to know when during boot the network card will be found on the bus.
To make this work reliably, the boot system need to be event based,
not sequence based.

There are other scenarios where the boot often fail too, but I guess
you get the idea. :)

[Svante Signell]

Post by Petter Reinholdtsen
[Svante Signell]

..

Post by Petter Reinholdtsen
Say you want to mount a network disk during boot. This depend on the
network being configured. This in turn might depend on a DHCP reply
from a DHCP server, and to send the DHCP request the network card need
to be detected. To detect the network card, the network driver need
to be loaded, and the network card need to be found on the PCI or some
other internal bus. And with the Linux kernel today, there is no way
to know when during boot the network card will be found on the bus.

This is the whole cause of the problem: You don't know the names of your
devices ay longer. Blame Linus!
What's the point of changing names of peripheral devices "dynamically"?
I've been struggling with eth0 and eth1 for some rime now, never knowing
how it will be named for every new kernel :-(

[Ben Hutchings]

Post by Svante Signell

Post by Petter Reinholdtsen
[Svante Signell]

..

Post by Petter Reinholdtsen
Say you want to mount a network disk during boot. This depend on the
network being configured. This in turn might depend on a DHCP reply
from a DHCP server, and to send the DHCP request the network card need
to be detected. To detect the network card, the network driver need
to be loaded, and the network card need to be found on the PCI or some
other internal bus. And with the Linux kernel today, there is no way
to know when during boot the network card will be found on the bus.

This is the whole cause of the problem: You don't know the names of your
devices ay longer. Blame Linus!

Blame the hardware manufacturers for implementing plug-and-play. Why
did they make it easy to add peripherals? Configuring IRQs and
addresses and linking the right drivers really filtered out the lusers
who shouldn't use computers.

Post by Svante Signell
What's the point of changing names of peripheral devices "dynamically"?
I've been struggling with eth0 and eth1 for some rime now, never knowing
how it will be named for every new kernel :-(

Clearly we should enumerate and initialise all hardware in serial, so
you have more time to admire the boot process.

Or, you know, use udev and let it take care of persistent naming.

Ben.

[Petter Reinholdtsen]

[Svante Signell]

Post by Svante Signell
This is the whole cause of the problem: You don't know the names of your
devices ay longer. Blame Linus!
What's the point of changing names of peripheral devices "dynamically"?
I've been struggling with eth0 and eth1 for some rime now, never knowing
how it will be named for every new kernel :-(

This is not a question of knowing the device names. It is a question
of the kernel device not being initialized and ready when it is needed
during boot. Having static entries in /dev/ would not help in any of
the scenarios I described.

The removal of the big kernel lock made the kernel less predictable,
and is the source of these issues. :)

[Russell Coker]

Post by Svante Signell
I've been struggling with eth0 and eth1 for some rime now, never knowing
how it will be named for every new kernel :-(

Fortunately udev allows us to assign static names for Ethernet devices. This
means that if you have an existing eth0 which is being used and then add
another Ethernet card you don't have eth0 become eth1 and then deny logins
(which is annoying for a server without a monitor). It also means that if the
hardware that provides eth0 dies you don't have eth1 become eth0 and then have
no match of interface and IP address to allow logins.

Finally it's handy to be able to use names such as mb0 for a motherboard based
port and pcia0/pcia1 for two ports on a card in PCI slot A.

It was possible to do this before udev, but udev made it a lot easier.

[Jon Dowland]

Post by Russell Coker
Fortunately udev allows us to assign static names for Ethernet devices. This
means that if you have an existing eth0 which is being used and then add
another Ethernet card you don't have eth0 become eth1 and then deny logins
(which is annoying for a server without a monitor). It also means that if the
hardware that provides eth0 dies you don't have eth1 become eth0 and then have
no match of interface and IP address to allow logins.

Also, I'm fairly sure udev does this by default in Debian, so the first
interface to get eth0 (identified by MAC address) gets eth0 afterwards, no
matter what order things come up.

[Ritesh Raj Sarraf]

Post by Svante Signell

Post by Petter Reinholdtsen
Say you want to mount a network disk during boot. This depend on the

Post by Petter Reinholdtsen
network being configured. This in turn might depend on a DHCP
reply from a DHCP server, and to send the DHCP request the
network card need to be detected. To detect the network card,
the network driver need to be loaded, and the network card need
to be found on the PCI or some other internal bus. And with
the Linux kernel today, there is no way to know when during
boot the network card will be found on the bus.

This is the whole cause of the problem: You don't know the names of
your devices ay longer. Blame Linus! What's the point of changing
names of peripheral devices "dynamically"? I've been struggling
with eth0 and eth1 for some rime now, never knowing how it will be
named for every new kernel :-(

I think he is talking about when the devices get discovered and in
what order. For naming, linux does have ways to guarantee persistent
device names, both for block and network devices.


- --
Given the large number of mailing lists I follow, I request you to CC me
in replies for quicker response

[Russ Allbery]

Post by Petter Reinholdtsen
Say you want to mount a network disk during boot. This depend on the
network being configured. This in turn might depend on a DHCP reply
from a DHCP server, and to send the DHCP request the network card need
to be detected. To detect the network card, the network driver need to
be loaded, and the network card need to be found on the PCI or some
other internal bus. And with the Linux kernel today, there is no way to
know when during boot the network card will be found on the bus. To
make this work reliably, the boot system need to be event based, not
sequence based.

And lest someone think this is a theoretical exercise, we *frequently* get
bugs filed against packages like OpenAFS, the Kerberos KDCs, or OpenLDAP
that are boot-order-dependent and network-dependent and either don't start
or start in unuseful ways or at unuseful times because of lack of event
notification for when interfaces are *actually* ready or when network
devices are *really* available.

These bugs are essentially unresolvable without something that understands
kernel events and can use them as input into boot dependency processing.
This is why so many packages resort to adding "sleep" calls with random
delays to their init scripts in the hope that everything will be ready
after some arbitrary delay.

The alternative is to add significantly additional complexity to every
package like those listed above that needs the network to loop and retry
if the network isn't available when it first starts. This is a huge waste
of effort.

[Patrick Lauer]

Post by Russ Allbery

Post by Petter Reinholdtsen
Say you want to mount a network disk during boot. This depend on the
network being configured. This in turn might depend on a DHCP reply
from a DHCP server, and to send the DHCP request the network card need
to be detected. To detect the network card, the network driver need to
be loaded, and the network card need to be found on the PCI or some
other internal bus. And with the Linux kernel today, there is no way to
know when during boot the network card will be found on the bus. To
make this work reliably, the boot system need to be event based, not
sequence based.

I disagree. If you have stateful init scripts you just wait until the
needed event arrives / statechange happens, *then* mark it as started.

And during that time you let the init script handler run in a loop that
polls, say, every second if the other init script declares itself started.

Post by Russ Allbery
And lest someone think this is a theoretical exercise, we *frequently* get
bugs filed against packages like OpenAFS, the Kerberos KDCs, or OpenLDAP
that are boot-order-dependent and network-dependent and either don't start
or start in unuseful ways or at unuseful times because of lack of event
notification for when interfaces are *actually* ready or when network
devices are *really* available.

That looks like a lack of design to me - and random timeouts are
dangerous. It might work on a lightly loaded machine, most of the time.
It makes more sense to me to have meaningful return values :)

Post by Russ Allbery
These bugs are essentially unresolvable without something that understands
kernel events

... udev/mdev/ /sys/kernel/uevent_helper to the rescue ...

Post by Russ Allbery
and can use them as input into boot dependency processing.

and now you're just reimagining OpenRC ;)

Post by Russ Allbery
This is why so many packages resort to adding "sleep" calls with random
delays to their init scripts in the hope that everything will be ready
after some arbitrary delay.
The alternative is to add significantly additional complexity to every
package like those listed above that needs the network to loop and retry
if the network isn't available when it first starts. This is a huge waste
of effort.

... or make the wrappers around init scripts smart enough, so you have
marginal complexity in one place.

Don't Repeat Yourself applies to init scripts too, there's no need to
have more than a #! line as boilerplate.

Just for fun, here's all the logic we need to get rsyncd started, *and*
it only starts once network is properly up (where the definition of "up"
is user-configurable as we often disagree on it):

#!/sbin/runscript
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/net-misc/rsync/files/rsyncd.init.d-r1,v 1.1
2012/03/22 22:01:21 idl0r Exp $

command="/usr/bin/rsync"
command_args="--daemon ${RSYNC_OPTS}"
pidfile="/var/run/${SVCNAME}.pid"

depend() {
use net
}

Because repeating yourself is tedious we have default functions now, so
no need for explicit start and stop - it just works.


Enjoy,

Patrick

[Russ Allbery]

Post by Patrick Lauer
Just for fun, here's all the logic we need to get rsyncd started, *and*
it only starts once network is properly up (where the definition of "up"
#!/sbin/runscript
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
/var/cvsroot/gentoo-x86/net-misc/rsync/files/rsyncd.init.d-r1,v 1.1
2012/03/22 22:01:21 idl0r Exp $
command="/usr/bin/rsync"
command_args="--daemon ${RSYNC_OPTS}"
pidfile="/var/run/${SVCNAME}.pid"
depend() {
use net
}

That's all nice and good from a syntax perspective, but we already have
the virtual facility $network in our current system. The question is:
what does "use net" *do*?

If it doesn't wait until the interface is fully configured via DHCP, it's
useless for solving the problem that I'm talking about, and that's much
more complicated than just doing init script ordering since it involves
more than just waiting for daemons to start.

As mentioned before, I really don't care what init system we use and I'm
happy to adjust my packages to use whatever. I just want to make sure
that it will *actually solve the problems*, not just add another level of
hand-waving. The problems that I'm particularly concerned about are:

* Tracking the processes started by an init script so that they can be
killed properly without doing bogus matching on process names, using
/proc information to see if they're a particular executable (which is
fragile when what you're doing is upgrading that executable and you may
not want to stop it first), or particularly PID files.

* Automatically restarting services that crash, similar to what
daemontools or runit can do.

* Real event awareness at the kernel level so that it knows when parts of
the system are *actually* available without guessing, using random
delays, or making assumptions about the implications of other daemons
having been started.

* Getting rid of all the boilerplate in init scripts and reducing them to
only the information that's actually interesting and might change.

I know upstart and systemd do all of those things for the platforms for
which they're available. I know that the current init system does none of
those things. According to this thread, I know OpenRC does do several of
those things. If it also does all of those things, great! That makes it
a very interesting contender. If it doesn't do all of those things and
can't be made to do all those things with roughly the same amount of
effort it would take to port upstart or systemd to kFreeBSD, it ceases to
be an interesting contender for me personally.

The conversation has gotten a bit frustrating, so I feel compelled to say
explicitly (not aimed at you, Patrick) that I'm completely uninterested
personally in arguments that I shouldn't care about those features. I do,
and I'm extremely unlikely to change my mind.

[Bernd Zeimetz]

Post by Russ Allbery

Post by Petter Reinholdtsen
Say you want to mount a network disk during boot. This depend on the
network being configured. This in turn might depend on a DHCP reply
from a DHCP server, and to send the DHCP request the network card need
to be detected. To detect the network card, the network driver need to
be loaded, and the network card need to be found on the PCI or some
other internal bus. And with the Linux kernel today, there is no way to
know when during boot the network card will be found on the bus. To
make this work reliably, the boot system need to be event based, not
sequence based.

And lest someone think this is a theoretical exercise, we *frequently* get
bugs filed against packages like OpenAFS, the Kerberos KDCs, or OpenLDAP
that are boot-order-dependent and network-dependent and either don't start
or start in unuseful ways or at unuseful times because of lack of event
notification for when interfaces are *actually* ready or when network
devices are *really* available.

How do you define "really available"? When the link is up (and your
favourite cisco is still blocking traffic to figure out its STP fun?) or
you default gateway is pingable (and waits for you to start your
VPN/authentication/whatever stuff)... and so on. There is always a
reason why you need to configure something manually for the special
cases - I can't see why an event driven system would be reduce the pain
enough to make it worth the hassle to migrate to it.

Post by Russ Allbery
These bugs are essentially unresolvable without something that understands
kernel events and can use them as input into boot dependency processing.
This is why so many packages resort to adding "sleep" calls with random
delays to their init scripts in the hope that everything will be ready
after some arbitrary delay.
The alternative is to add significantly additional complexity to every
package like those listed above that needs the network to loop and retry
if the network isn't available when it first starts. This is a huge waste
of effort.

[Jonathan McDowell]

Post by Eray Aslan

Post by Arto Jantunen
Reliability in the case of modern kernels and modern hardware
means event based, not static. The hardware in a modern computer
comes and goes as it pleases (usb devices being the worst example,
but scanning

That's the thing. Hardware do not come and go as it pleases on my
servers and I do not want anything happening when someone inserts a
usb device. It's nice on my laptop but not on my servers.

It comes and goes on my servers. I bring online new storage devices,
and change their sizes when I decide I want more space. Sometimes I
bring online a lot of temporary space and then take it away when I'm
done. These are production servers with Fibre Channel attached storage
and this is not a unique use case. Having to manually fiddle with
rescan-scsi-bus etc to see the new devices is a PITA and I welcome any
attempt to make this a more seamless process.

Don't assume dynamic device detection is only about personal machines or
USB. It's useful in a much wider context.

J.

[Jonas Smedegaard]

Post by Jonathan McDowell

Post by Eray Aslan

Post by Arto Jantunen
Reliability in the case of modern kernels and modern hardware
means event based, not static. The hardware in a modern computer
comes and goes as it pleases (usb devices being the worst
example, but scanning

That's the thing. Hardware do not come and go as it pleases on my
servers and I do not want anything happening when someone inserts a
usb device. It's nice on my laptop but not on my servers.

It comes and goes on my servers. I bring online new storage devices,
and change their sizes when I decide I want more space. Sometimes I
bring online a lot of temporary space and then take it away when I'm
done. These are production servers with Fibre Channel attached storage
and this is not a unique use case. Having to manually fiddle with
rescan-scsi-bus etc to see the new devices is a PITA and I welcome any
attempt to make this a more seamless process.
Don't assume dynamic device detection is only about personal machines
or USB. It's useful in a much wider context.

Agreed it is *useful* in many cases.

But I also agree that it is not *required* in *all* cases.

I believe Debian still supports running locally compiled kernels which
do not depend on udev, and that some setups do not require udev either
(not everyone use fibre channel).


- Jonas

[Ben Hutchings]

Post by Jonas Smedegaard

Post by Jonathan McDowell

Post by Eray Aslan

Post by Arto Jantunen
Reliability in the case of modern kernels and modern hardware
means event based, not static. The hardware in a modern computer
comes and goes as it pleases (usb devices being the worst
example, but scanning

That's the thing. Hardware do not come and go as it pleases on my
servers and I do not want anything happening when someone inserts a
usb device. It's nice on my laptop but not on my servers.

It comes and goes on my servers. I bring online new storage devices,
and change their sizes when I decide I want more space. Sometimes I
bring online a lot of temporary space and then take it away when I'm
done. These are production servers with Fibre Channel attached storage
and this is not a unique use case. Having to manually fiddle with
rescan-scsi-bus etc to see the new devices is a PITA and I welcome any
attempt to make this a more seamless process.
Don't assume dynamic device detection is only about personal machines
or USB. It's useful in a much wider context.

Agreed it is *useful* in many cases.
But I also agree that it is not *required* in *all* cases.
I believe Debian still supports running locally compiled kernels which
do not depend on udev, and that some setups do not require udev either
(not everyone use fibre channel).

It is supported only in the sense that it is not yet impossible.

Please don't ask anyone to spend time to avoid udev dependencies;
hotplugging is normal and udev is the proper way to handle all
devices the Linux kernel finds.

Ben.

[Adam Borowski]

Post by Ben Hutchings

Post by Jonas Smedegaard
I believe Debian still supports running locally compiled kernels which
do not depend on udev, and that some setups do not require udev either
(not everyone use fibre channel).

It is supported only in the sense that it is not yet impossible.
Please don't ask anyone to spend time to avoid udev dependencies;
hotplugging is normal and udev is the proper way to handle all
devices the Linux kernel finds.

No udev dependencies in the userland are a good thing: this simplifies
chroots, vservers, etc.

No udev dependencies wrt handling real hardware are a waste of time, and
complicate stuff.

[Patrick Lauer]

Post by Adam Borowski

Post by Ben Hutchings

Post by Jonas Smedegaard
I believe Debian still supports running locally compiled kernels which
do not depend on udev, and that some setups do not require udev either
(not everyone use fibre channel).

It is supported only in the sense that it is not yet impossible.
Please don't ask anyone to spend time to avoid udev dependencies;
hotplugging is normal and udev is the proper way to handle all
devices the Linux kernel finds.

udev is just the reference implementation. mdev [part of busybox] can do
the same (modulo rules: it has a slightly simpler format that doesn't
provide exactly the same features (yet))

All you need is a netlink socket and a listener that understands the
kernel events coming in ...

They are even enumerated so you can choose to serialize them (which, in
general, is a good idea).

And I still haven't figured out what things you can do with
/sys/kernel/uevent_helper :)

Post by Adam Borowski
No udev dependencies in the userland are a good thing: this simplifies
chroots, vservers, etc.
No udev dependencies wrt handling real hardware are a waste of time, and
complicate stuff.

on a vserver you might be able to work with a devtmpfs only, but using
mdev seems to work quite well too.

The only real dependency on udev is libudev/gudev, and that "only"
affects the Big Desktop Environments for now, as far as I can tell.

Take care,

Patrick

[Ben Hutchings]

Post by Patrick Lauer

Post by Ben Hutchings

Post by Jonas Smedegaard
I believe Debian still supports running locally compiled kernels which
do not depend on udev, and that some setups do not require udev either
(not everyone use fibre channel).

It is supported only in the sense that it is not yet impossible.
Please don't ask anyone to spend time to avoid udev dependencies;
hotplugging is normal and udev is the proper way to handle all
devices the Linux kernel finds.

udev is just the reference implementation. mdev [part of busybox] can do
the same (modulo rules: it has a slightly simpler format that doesn't
provide exactly the same features (yet))

[...]

Sure, for Linux in general you have other options like mdev. However,
Debian uses udev.

Ben.

[Bernd Zeimetz]

Post by Ben Hutchings

Post by Patrick Lauer

Post by Ben Hutchings

Post by Jonas Smedegaard
I believe Debian still supports running locally compiled kernels
which do not depend on udev, and that some setups do not require
udev either (not everyone use fibre channel).

It is supported only in the sense that it is not yet impossible.
Please don't ask anyone to spend time to avoid udev dependencies;
hotplugging is normal and udev is the proper way to handle all
devices the Linux kernel finds.

udev is just the reference implementation. mdev [part of busybox] can do
the same (modulo rules: it has a slightly simpler format that doesn't
provide exactly the same features (yet))

[...]
Sure, for Linux in general you have other options like mdev. However,
Debian uses udev.

Debian installs udev by default, but as with other init systems it should not
stop your from using whatever-you-like instead of udev.

[Ben Hutchings]

Post by Bernd Zeimetz

Post by Ben Hutchings

Post by Patrick Lauer

Post by Ben Hutchings

Post by Jonas Smedegaard
I believe Debian still supports running locally compiled kernels
which do not depend on udev, and that some setups do not require
udev either (not everyone use fibre channel).

It is supported only in the sense that it is not yet impossible.
Please don't ask anyone to spend time to avoid udev dependencies;
hotplugging is normal and udev is the proper way to handle all
devices the Linux kernel finds.

udev is just the reference implementation. mdev [part of busybox] can do
the same (modulo rules: it has a slightly simpler format that doesn't
provide exactly the same features (yet))

[...]
Sure, for Linux in general you have other options like mdev. However,
Debian uses udev.

Debian installs udev by default, but as with other init systems it should not
stop your from using whatever-you-like instead of udev.

Of course, Debian has many derivative distributions that use some
alternate components.

Ben.

[Bernd Zeimetz]

Post by Bernd Zeimetz

Post by Ben Hutchings

Post by Patrick Lauer

Post by Ben Hutchings

Post by Jonas Smedegaard
I believe Debian still supports running locally compiled
kernels which do not depend on udev, and that some setups do
not require udev either (not everyone use fibre channel).

It is supported only in the sense that it is not yet impossible.
Please don't ask anyone to spend time to avoid udev dependencies;
hotplugging is normal and udev is the proper way to handle all
devices the Linux kernel finds.

udev is just the reference implementation. mdev [part of busybox] can
do the same (modulo rules: it has a slightly simpler format that
doesn't provide exactly the same features (yet))

[...]
Sure, for Linux in general you have other options like mdev. However,
Debian uses udev.

Debian installs udev by default, but as with other init systems it should
not stop your from using whatever-you-like instead of udev.

Of course, Debian has many derivative distributions that use some alternate
components.

Please stop trolling.
There is no reason why we should not allow people to use mdev or whatever they
like instead of udev.

[Ben Hutchings]

Post by Bernd Zeimetz

Post by Bernd Zeimetz

Post by Ben Hutchings

Post by Patrick Lauer

Post by Ben Hutchings

Post by Jonas Smedegaard
I believe Debian still supports running locally compiled
kernels which do not depend on udev, and that some setups do
not require udev either (not everyone use fibre channel).

It is supported only in the sense that it is not yet impossible.
Please don't ask anyone to spend time to avoid udev dependencies;
hotplugging is normal and udev is the proper way to handle all
devices the Linux kernel finds.

udev is just the reference implementation. mdev [part of busybox] can
do the same (modulo rules: it has a slightly simpler format that
doesn't provide exactly the same features (yet))

[...]
Sure, for Linux in general you have other options like mdev. However,
Debian uses udev.

Debian installs udev by default, but as with other init systems it should
not stop your from using whatever-you-like instead of udev.

Of course, Debian has many derivative distributions that use some alternate
components.

Please stop trolling.
There is no reason why we should not allow people to use mdev or whatever they
like instead of udev.

I'm perfectly serious. You may be able to do that today, but you should
not expect it to work and should not report a bug if you are later
forced to install udev as a depdendency of some other package.

Ben.

[Adrian Knoth]

Post by Jonas Smedegaard
I believe Debian still supports running locally compiled kernels which
do not depend on udev, and that some setups do not require udev either
(not everyone use fibre channel).

Speaking of which: there was a somewhat related comment from GregkH
yesterday:

https://plus.google.com/u/0/111049168280159033135/posts/V2t57Efkf1s


Money quote:

'I seriously wonder how much longer a "general" distribution such as
Gentoo or Debian can keep up the charade of trying to provide all
options for all users.'


'I strongly recommend tightly-coupled distros for desktops for
anyone (like Fedora or openSUSE or Ubuntu), and Debian or Gentoo only
for servers or embedded systems"'


And then, there is this statement about the core distro:

"There are a number of folk in the Linux ecosystem pushing for a
small core of tightly coupled components to make the core of a modern
linux distro. The idea is that this “core distro” can evolve in sync
with the kernel, and generally move fast. This is both good for the
overall platform and very hard to implement for the “universal”
distros."



I thought I'd pass it along, since it mentions "Debian" multiple times.


Cheers

[Roger Leigh]

Post by Adrian Knoth

Post by Jonas Smedegaard
I believe Debian still supports running locally compiled kernels which
do not depend on udev, and that some setups do not require udev either
(not everyone use fibre channel).

"There are a number of folk in the Linux ecosystem pushing for a
small core of tightly coupled components to make the core of a modern
linux distro. The idea is that this “core distro” can evolve in sync
with the kernel, and generally move fast. This is both good for the
overall platform and very hard to implement for the “universal”
distros."

I hope I'm not alone in feeling quite uneasy about the implications
of the above.

One of the definining characteristics of the Linux ecosystem, including
Debian, has been that the system has been made up of a set of loosely-
coupled compoments with well-defined interfaces. This is in stark
contrast to, e.g. Windows, MacOS and other proprietary systems, which
have extremely tight coupling between their components, and where being
able to swap out one component for another is almost unheard of. Given
that this loose coupling has enabled experimentation with a wide
variety of different solutions to problems, and allowed the evolution
of a diverse range of different packages to solve a very wide variety
of needs, it could be considered one of the defining factors in the
success of Linux. Quite why we would want to replace this with a
one-size-fits-all solution beggars belief.

Given the ongoing debate regarding the different init systems we might
want to adopt long-term, I think this is perhaps one of the less
discussed factors, but perhaps one of the more important ones. Both
systemd and upstart are technically superior to all the alternatives,
systemd perhaps more so. But while the technical advantages are nice,
these come at the cost of reducing the amount of diversity in the
system, and our ability to replace pieces which don't fit our needs
due to the tight coupling.

While sysvinit is clearly inferior, it gives us (Debian) something the
others do not: control over our own destiny, and the ability to
modify every aspect of it and the init scripts to fit our needs. Both
systemd and upstart are largely influenced by third parties. As a
trivial example: systemd creates user session information in
/run/user/$user . I brought up with lennart the fact that this would
only permit one session per user. He rejected out of hand the fact
that more than one session would ever be needed, because Gnome only
allowed one session per user. So the limitations of Gnome in this
respect have led to a fundamental limitation in systemd's session
management.

We could patch and work around this type of brokenness easily enough.
But given the rapid speed at which systemd is growing and swallowing
up more and more functionality previously served by different tools,
would we have the ability and will to continue to patch every bit that
didn't fit our needs, and keep that working over time? If we can't,
we'll potentialy end up with a technically superior system... which
meets the needs of Gnome/Fedora and other distributions, rather than
our own. And when the primary maintainers have shown themselves to
be less than willing to accommodate even this simplest of requests
(as above; a single tempnam call would have been sufficient), would
we be committing ourselves to a less than desirable fate?


Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800

[Marco d'Itri]

Post by Roger Leigh
I hope I'm not alone in feeling quite uneasy about the implications
of the above.

We can all be "uneasy" about it until we are blue in the face, but since
Red Hat maintains most Linux core components and we do not, there is not
much we can do about it.

Post by Roger Leigh
While sysvinit is clearly inferior, it gives us (Debian) something the
others do not: control over our own destiny, and the ability to
modify every aspect of it and the init scripts to fit our needs. Both
systemd and upstart are largely influenced by third parties. As a

I do not consider settling for obsolete software to be a useful
direction for Debian, nor is NIH a great argument in software design.

[Svante Signell]

Post by Marco d'Itri

Post by Roger Leigh
I hope I'm not alone in feeling quite uneasy about the implications
of the above.

We can all be "uneasy" about it until we are blue in the face, but since
Red Hat maintains most Linux core components and we do not, there is not
much we can do about it.

Maybe GNU/Linux is not the bright future any longer.

Post by Marco d'Itri

Post by Roger Leigh
While sysvinit is clearly inferior, it gives us (Debian) something the
others do not: control over our own destiny, and the ability to
modify every aspect of it and the init scripts to fit our needs. Both
systemd and upstart are largely influenced by third parties. As a

I do not consider settling for obsolete software to be a useful
direction for Debian, nor is NIH a great argument in software design.

Talking about NIH, is systemd not that if anything?

[Jonathan Nieder]

Post by Marco d'Itri
We can all be "uneasy" about it until we are blue in the face, but since
Red Hat maintains most Linux core components and we do not, there is not
much we can do about it.

I'll repeat what I said last time you made this (in my opinion
strange) argument:

Red Hat employs some eminently friendly and reasonable people.
Claiming that we are at their mercy is ignoring the ability to reason
with them. (When that stops being true, we can talk about whether it
is time to work with other distros on a fork, but given that we're not
there yet, I wonder why you keep on raising the point.)

[Marco d'Itri]

Post by Jonathan Nieder
Red Hat employs some eminently friendly and reasonable people.

I am on friendly terms with many Red Hat people, but it is a fact that
they take design decisions which are aligned with the needs of RHEL
and these needs are often far from what is good for other distributions.
This has been happening more and more after SuSE has become irrelevant.

I will cite just a few simple examples:
- no good strategy to prevent lockstep udev/kernel upgrades, since RHEL
does not support upgrading to the next major release
- configuration files in /etc/ overriding configuration files in /lib/,
to work around the inferior configuration files handling of RPM
- removal from udev/systemd of features which Red Hat will not provide
anymore (e.g. support of persistent names for new network interfaces,
choose your own example for systemd)

Post by Jonathan Nieder
Claiming that we are at their mercy is ignoring the ability to reason
with them.

The problem is not "reasoning", in my experience Red Hat people will
promply agree that different distributions can make different choices.
But nowadays they just refuse to support these choices.
Obviously this is their prerogative, but it is also a fact which we need
to be aware of.

[Uoti Urpala]

Post by Marco d'Itri
I am on friendly terms with many Red Hat people, but it is a fact that
they take design decisions which are aligned with the needs of RHEL
and these needs are often far from what is good for other distributions.
- configuration files in /etc/ overriding configuration files in /lib/,
to work around the inferior configuration files handling of RPM

I'm not convinced that the traditional Debian way of directly editing
package-created files under /etc would be preferable. I think the
etc-overrides-lib alternative is technically superior in many ways: the
original version is kept in a known location, it's trivial to
(temporarily) revert to defaults when you suspect a problem is caused by
local configuration, it's easier to see what has been locally modified
and what hasn't, and especially if the program supports file inclusion
(to include then override the default version) you can resolve more
updates without needing to do 3-way merges by hand.

The main argument against etc-overrides-lib has been that dpkg can
automatically give warnings about some of the cases where you may need
to update your local configuration. But this ability isn't really
inherent to the directly-editing case, nor only implementable with it. I
think this is better characterized as a case of Debian preferring an
inferior format because that's the only thing its existing tools already
support, while Red Hat is free to choose the superior format without
drawbacks as it never had such tools at all.

[Dmitry Nezhevenko]

Post by Uoti Urpala

Post by Marco d'Itri
I am on friendly terms with many Red Hat people, but it is a fact that
they take design decisions which are aligned with the needs of RHEL
and these needs are often far from what is good for other distributions.
- configuration files in /etc/ overriding configuration files in /lib/,
to work around the inferior configuration files handling of RPM

I'm not convinced that the traditional Debian way of directly editing
package-created files under /etc would be preferable. I think the
etc-overrides-lib alternative is technically superior in many ways: the
original version is kept in a known location, it's trivial to
(temporarily) revert to defaults when you suspect a problem is caused by
local configuration, it's easier to see what has been locally modified
and what hasn't, and especially if the program supports file inclusion
(to include then override the default version) you can resolve more
updates without needing to do 3-way merges by hand.
The main argument against etc-overrides-lib has been that dpkg can
automatically give warnings about some of the cases where you may need
to update your local configuration. But this ability isn't really
inherent to the directly-editing case, nor only implementable with it. I

Currently dpkg allows not only warnings about "some of the cases". It
always warns user when config file was changed in package and user edited
installed copy. And provides a a nice way to quickly take a look to
changes, choose which version to use or even start shell for resolving it
manually. So you just can't miss time when config should be edited at all.

With "etc-overrides-lib" it's not possible at all...

[Uoti Urpala]

Post by Dmitry Nezhevenko

Post by Uoti Urpala

Post by Marco d'Itri
- configuration files in /etc/ overriding configuration files in /lib/,
to work around the inferior configuration files handling of RPM

I'm not convinced that the traditional Debian way of directly editing
package-created files under /etc would be preferable. I think the
etc-overrides-lib alternative is technically superior in many ways: the
original version is kept in a known location, it's trivial to
(temporarily) revert to defaults when you suspect a problem is caused by
local configuration, it's easier to see what has been locally modified
and what hasn't, and especially if the program supports file inclusion
(to include then override the default version) you can resolve more
updates without needing to do 3-way merges by hand.
The main argument against etc-overrides-lib has been that dpkg can
automatically give warnings about some of the cases where you may need
to update your local configuration. But this ability isn't really
inherent to the directly-editing case, nor only implementable with it. I

Currently dpkg allows not only warnings about "some of the cases". It
always warns user when config file was changed in package and user edited
installed copy. And provides a a nice way to quickly take a look to
changes, choose which version to use or even start shell for resolving it
manually. So you just can't miss time when config should be edited at all.

Wrong. Any program behavior change may require changing custom
configuration, but such changes need not be accompanied by changes in
the default configuration file. Currently dpkg lacks any mechanism to
show warnings in these cases, even if the maintainers are aware of it.
The only workaround would be to make dummy changes to the configuration
files just to trigger the dpkg warnings, but this would cause other
problems. Thus "can't miss at all" is false.

Post by Dmitry Nezhevenko
With "etc-overrides-lib" it's not possible at all...

This is not true either. You could develop tools that work in this case.
I think there is no fundamental reason why such tools couldn't work
better than current dpkg behavior with equal effort. An easy starting
point (requiring no per-package work at all) would be to show a warning
if an updated package owns a directory under /etc, and that directory
contains non-package-owned files. With some extra work, still no worse
than what's required for current dpkg handling, you should be able to
include information about changes to the corresponding default files (if
any).

[Dmitry Nezhevenko]

Post by Uoti Urpala

Post by Dmitry Nezhevenko
Currently dpkg allows not only warnings about "some of the cases". It
always warns user when config file was changed in package and user edited
installed copy. And provides a a nice way to quickly take a look to
changes, choose which version to use or even start shell for resolving it
manually. So you just can't miss time when config should be edited at all.

Wrong. Any program behavior change may require changing custom
configuration, but such changes need not be accompanied by changes in
the default configuration file. Currently dpkg lacks any mechanism to
show warnings in these cases, even if the maintainers are aware of it.
The only workaround would be to make dummy changes to the configuration
files just to trigger the dpkg warnings, but this would cause other
problems. Thus "can't miss at all" is false.

You are talking about changing "default" values, right? Other cases
("option do_foo starts doing something called bar instead" seems just like
bugs). But even for changing default, a lot of software with editable by
hands config files usually are shipped with well commented options and
commented out default value. Something like this (from dovecot.conf):

# If you want to specify non-default ports or anything more complex,
# edit conf.d/master.conf.
#listen = *, ::

# Base directory where to store runtime data.
#base_dir = /var/run/dovecot/

# Name of this instance. Used to prefix all Dovecot processes in ps
# output.
#instance_name = dovecot

So if upstream will decide to change default value, they will also update
configuration file and this will trigger dpkg handling of changed
conffiles.

Post by Uoti Urpala

Post by Dmitry Nezhevenko
With "etc-overrides-lib" it's not possible at all...

This is not true either. You could develop tools that work in this case.
I think there is no fundamental reason why such tools couldn't work
better than current dpkg behavior with equal effort. An easy starting
point (requiring no per-package work at all) would be to show a warning
if an updated package owns a directory under /etc, and that directory
contains non-package-owned files. With some extra work, still no worse
than what's required for current dpkg handling, you should be able to
include information about changes to the corresponding default files (if
any).

Yeah. I agree. It's _currently_ not possible at all. But again, it's
possible but introduce new issues complications for users.

By default Debian users are aware that files in /etc are supposed to be
edited by user (directly using editor or via special tool, like passwd can
be edited using useradd/userdel). So if you're using software for a first
time, you can just do "dpkg-query -L cooldaemon | grep /etc" to find out it's
configuration file, quickly edit it and that's all you need. In simple
cases where configuration files are full of comments, you even don't need
to open documentation.

Now compare this with "etc-overrides-lib" case. You're doing same
dpkg-query -L and it show nothing in /etc (or just empty directory if you
are lucky) and a lot of stuff pieces of which looks like a config in /lib,
/usr/lib, /usr/share or any other place. So you should carefully read
documentation to find out, is it possible at all to override such file,
and if yes, how an where to copy these them before editing.

-- WBR, Dmitry

[Jonathan Nieder]

Post by Marco d'Itri
This has been happening more and more after SuSE has become irrelevant.
- no good strategy to prevent lockstep udev/kernel upgrades, since RHEL
does not support upgrading to the next major release
- configuration files in /etc/ overriding configuration files in /lib/,
to work around the inferior configuration files handling of RPM
- removal from udev/systemd of features which Red Hat will not provide
anymore (e.g. support of persistent names for new network interfaces,
choose your own example for systemd)

Thanks for explaining. Very interesting examples.

Possible conclusions:
- we need to be involved upstream in core projects if we do not want to
be neglected
- improving OpenSuSE and other distros is another way to help upstreams
remember how to support more than one setup
- helping RPM and other Red Hat infrastructure is valuable, so they can
experience the features that it would be nice to preserve in Debian
- sometimes package maintenance involves hard dilemmas

[Steve McIntyre]

Post by Marco d'Itri

Post by Jonathan Nieder
Claiming that we are at their mercy is ignoring the ability to reason
with them.

The problem is not "reasoning", in my experience Red Hat people will
promply agree that different distributions can make different choices.
But nowadays they just refuse to support these choices.
Obviously this is their prerogative, but it is also a fact which we need
to be aware of.

If that's really the case, then we should be looking at other options
that *will* support what we want/need rather than simply meekly
following.

[Roger Leigh]

Post by Marco d'Itri

Post by Roger Leigh
While sysvinit is clearly inferior, it gives us (Debian) something the
others do not: control over our own destiny, and the ability to
modify every aspect of it and the init scripts to fit our needs. Both
systemd and upstart are largely influenced by third parties. As a

I do not consider settling for obsolete software to be a useful
direction for Debian, nor is NIH a great argument in software design.

Just to be clear, I am by no means suggesting that we should stick
with sysvinit. I am merely pointing out that there are important
factors to consider /in addition to/ the technical merits of the init
system. With systemd we get a technically excellent system, but we are
also buying into a whole lot more than that, some good, some bad.

Keeping our options open, and evaluating what are options are
available and usable is important, and this is the principal reason
why I am interested in looking at OpenRC. It doesn't hurt to try it
out and see if it meets our needs.


Roger

[Fernando Lemos]

Post by Roger Leigh
Keeping our options open, and evaluating what are options are
available and usable is important, and this is the principal reason
why I am interested in looking at OpenRC.  It doesn't hurt to try it
out and see if it meets our needs.

Agreed on the "keeping our options open" part. But given that the
kernel is increasingly event-based, OpenRC seems to be a step
backwards. I agree that OpenRC would be an improvement over the status
quo, but migrating *away* from OpenRC later on would be a major pain
as we would have to support both LSB/sysvinit scripts and OpenRC
service descriptions for the foreseeable future.

Regards,

[Fernando Lemos]

Post by Roger Leigh
One of the definining characteristics of the Linux ecosystem, including
Debian, has been that the system has been made up of a set of loosely-
coupled compoments with well-defined interfaces.  This is in stark
contrast to, e.g. Windows, MacOS and other proprietary systems, which
have extremely tight coupling between their components, and where being
able to swap out one component for another is almost unheard of.  Given
that this loose coupling has enabled experimentation with a wide
variety of different solutions to problems, and allowed the evolution
of a diverse range of different packages to solve a very wide variety
of needs, it could be considered one of the defining factors in the
success of Linux.  Quite why we would want to replace this with a
one-size-fits-all solution beggars belief.

Just to be clear, what you're describing is specific to systemd, not
to event-based init systems in general.

It's true that diversity fosters innovation. I think the question here
is, should Debian make technical choices based on whether or not the
resulting distribution is an ambient that fosters innovation on init
system design? And when I think of it that way, the answer seems to be
a resounding no.

Post by Roger Leigh
Given the ongoing debate regarding the different init systems we might
want to adopt long-term, I think this is perhaps one of the less
discussed factors, but perhaps one of the more important ones.  Both
systemd and upstart are technically superior to all the alternatives,
systemd perhaps more so.  But while the technical advantages are nice,
these come at the cost of reducing the amount of diversity in the
system, and our ability to replace pieces which don't fit our needs
due to the tight coupling.

Just to be clear again, this is also specific to the current
event-based init implementations. It's not in any way a characteristic
of event-based init systems in general.

Integration versus flexibility is a tradeoff. At one end of the
spectrum, we have a very tightly integrated distribution, where
nothing is interchangeable. At the other end, we have the concept of
distribution as a simple collection of binaries with pretty much no
integration. Having a better integrated init system would push Debian
a little bit towards the former, no doubt.

Post by Roger Leigh
While sysvinit is clearly inferior, it gives us (Debian) something the
others do not: control over our own destiny, and the ability to
modify every aspect of it and the init scripts to fit our needs.  Both
systemd and upstart are largely influenced by third parties.  As a
trivial example: systemd creates user session information in
/run/user/$user .  I brought up with lennart the fact that this would
only permit one session per user.  He rejected out of hand the fact
that more than one session would ever be needed, because Gnome only
allowed one session per user.  So the limitations of Gnome in this
respect have led to a fundamental limitation in systemd's session
management.
We could patch and work around this type of brokenness easily enough.
But given the rapid speed at which systemd is growing and swallowing
up more and more functionality previously served by different tools,
would we have the ability and will to continue to patch every bit that
didn't fit our needs, and keep that working over time?  If we can't,
we'll potentialy end up with a technically superior system... which
meets the needs of Gnome/Fedora and other distributions, rather than
our own.  And when the primary maintainers have shown themselves to
be less than willing to accommodate even this simplest of requests
(as above; a single tempnam call would have been sufficient), would
we be committing ourselves to a less than desirable fate?

That's certainly something we need to take into account. There's an
option you didn't mention: forking. I think it's better to fork than
to try to come up with something from scratch. When people write stuff
from scratch, 9 out of 10 times they just don't understand the problem
they're trying to solve. And if it's a big project (such as an init
system), it's very unlikely to ever get off the ground.


Regards,

[Uoti Urpala]

Post by Roger Leigh
One of the definining characteristics of the Linux ecosystem, including
Debian, has been that the system has been made up of a set of loosely-
coupled compoments with well-defined interfaces. This is in stark
contrast to, e.g. Windows, MacOS and other proprietary systems, which
have extremely tight coupling between their components, and where being
able to swap out one component for another is almost unheard of. Given
that this loose coupling has enabled experimentation with a wide
variety of different solutions to problems, and allowed the evolution

Recent innovation related to init systems has largely happened in
systemd. More conservative approaches have failed to show enough
progress to solve even the immediate problems. IMO there's enough
evidence that the part which needed new innovation was the interfaces
and the integration between them, not the individual pieces trying to
work within the limitations of the old interfaces.

Post by Roger Leigh
While sysvinit is clearly inferior, it gives us (Debian) something the
others do not: control over our own destiny, and the ability to
modify every aspect of it and the init scripts to fit our needs. Both
systemd and upstart are largely influenced by third parties.
But given the rapid speed at which systemd is growing and swallowing
up more and more functionality previously served by different tools,
would we have the ability and will to continue to patch every bit that
didn't fit our needs, and keep that working over time? If we can't,
we'll potentialy end up with a technically superior system... which
meets the needs of Gnome/Fedora and other distributions, rather than
our own.

You're not offering any competitive alternative to systemd. In fact,
you're pretty much saying that that it's not realistic to maintain an
alternative. If you're given a choice between using Debian from 10 years
ago or the latest Fedora, would you choose the old Debian because "it
was made for our needs"? I think there's a quite direct equivalence
between preferring the 10-year-old Debian and preferring to stay with
sysvinit just to "control our own destiny".

[Chris Knadle]

Post by Patrick Lauer
Greetings,
in the last months there have been many discussions about init systems,
especially systemd. The current state seems to make no one really happy
- the current debian init system is a bit minimal and doesn't even do
stateful services in an elegant way (e.g. /etc/init.d/apache2 start;
/etc/init.d/apache2 start).

After testing systemd some, I've now grown a new appreciation for the default
Debian init system -- because it gives visual notification of what's been
started, where systemd does not. I'd like to know where OpenRC is in this
regard -- if it maintains visual notification at startup, that would be a
benefit it has that isn't currently mentioned at [1] AFAICT.

I think visual startup notification is significant. Often enough I find error
notifications during startup which I can then track down and fix, and if this
information is hidden then startup errors might not get noticed. :-/

[I do like that systemd can be loaded and you can choose when to turn it
on/off via passing 'init=/bin/systemd' to the booting kernel. That and the
fast bootup time are nice. Bootup time is not a significant benefit in my
case, as I'm using LUKS encryption with several long passwords to enter at
boot time. :-P]

...

Post by Patrick Lauer
What we offer you is a modern, slim, userfriendly init system with
minimal dependencies. All you need is a C99 compiler and a posix sh!
The list of features is long and tedious
http://wiki.gentoo.org/wiki/OpenRC )

(Note to the reader: this is the same page as [1].)

Some feedback on the page above: in the first table comparing system startup
types there are markers for notes, e.g. "no[1]" concerning Read-Ahead, but the
expected note details after the table seem to be missing.

Post by Patrick Lauer
Should you decide to switch (or just evaluate if switching is possible /
makes sense) you'll get full support from us in migrating init scripts
and figuring out all the nontrivial changes. Just visit us on IRC (
meet us for a beer or two.

For others looking to evaulate: at the tail end of [2] I found a link to the
OpenRC Git repository [3], along with more documentation on OpenRC and how to
migrate at [4].



[1] http://wiki.gentoo.org/wiki/OpenRC

[2] https://en.wikipedia.org/wiki/OpenRC

[3] http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git

[4] http://www.gentoo.org/proj/en/base/openrc/

-- Chris

--
Chris Knadle
***@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74

[Matthias Klumpp]

Hi!
AFAIK systemd supports startup notifications, even in colour - at
least it did this last time I tried (a few weeks ago)
Maybe your systemd version is too old?
(Quoting Lennart: "We now show the progress of fsck at boot on the
console, again. We also show the much loved colorful [ OK ] status
messages at boot again, as known from most SysV implementations.")
Regards,
Matthias

Post by Chris Knadle

Post by Patrick Lauer
Greetings,
in the last months there have been many discussions about init systems,
especially systemd. The current state seems to make no one really happy
- the current debian init system is a bit minimal and doesn't even do
stateful services in an elegant way (e.g. /etc/init.d/apache2 start;
/etc/init.d/apache2 start).

After testing systemd some, I've now grown a new appreciation for the default
Debian init system -- because it gives visual notification of what's been
started, where systemd does not.  I'd like to know where OpenRC is in this
regard -- if it maintains visual notification at startup, that would be a
benefit it has that isn't currently mentioned at [1] AFAICT.
I think visual startup notification is significant.  Often enough I find error
notifications during startup which I can then track down and fix, and if this
information is hidden then startup errors might not get noticed.  :-/
[I do like that systemd can be loaded and you can choose when to turn it
on/off via passing 'init=/bin/systemd' to the booting kernel.  That and the
fast bootup time are nice.  Bootup time is not a significant benefit in my
case, as I'm using LUKS encryption with several long passwords to enter at
boot time.  :-P]
...

Post by Patrick Lauer
What we offer you is a modern, slim, userfriendly init system with
minimal dependencies. All you need is a C99 compiler and a posix sh!
The list of features is long and tedious
http://wiki.gentoo.org/wiki/OpenRC )

(Note to the reader: this is the same page as [1].)
Some feedback on the page above: in the first table comparing system startup
types there are markers for notes, e.g. "no[1]" concerning Read-Ahead, but the
expected note details after the table seem to be missing.

Post by Patrick Lauer
Should you decide to switch (or just evaluate if switching is possible /
makes sense) you'll get full support from us in migrating init scripts
and figuring out all the nontrivial changes. Just visit us on IRC (
meet us for a beer or two.

For others looking to evaulate:  at the tail end of [2] I found a link to the
OpenRC Git repository [3], along with more documentation on OpenRC and how to
migrate at [4].
[1] http://wiki.gentoo.org/wiki/OpenRC
[2] https://en.wikipedia.org/wiki/OpenRC
[3] http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git
[4] http://www.gentoo.org/proj/en/base/openrc/
 -- Chris
--
Chris Knadle
GPG Key: 4096R/0x1E759A726A9FDD74

[Milan P. Stanic]

Post by Matthias Klumpp
Hi!
AFAIK systemd supports startup notifications, even in colour - at
least it did this last time I tried (a few weeks ago)

Yes, it does but on wide screen it is not so easy to follow it because
status (OK, Failed ...) are on the right end.

It would be better if the status are on the beginning of the line.

Post by Matthias Klumpp
Maybe your systemd version is too old?
(Quoting Lennart: "We now show the progress of fsck at boot on the
console, again. We also show the much loved colorful [ OK ] status
messages at boot again, as known from most SysV implementations.")
Regards,
Matthias

Post by Chris Knadle

Post by Patrick Lauer
Greetings,
in the last months there have been many discussions about init systems,
especially systemd. The current state seems to make no one really happy
- the current debian init system is a bit minimal and doesn't even do
stateful services in an elegant way (e.g. /etc/init.d/apache2 start;
/etc/init.d/apache2 start).

After testing systemd some, I've now grown a new appreciation for the default
Debian init system -- because it gives visual notification of what's been
started, where systemd does not.  I'd like to know where OpenRC is in this
regard -- if it maintains visual notification at startup, that would be a
benefit it has that isn't currently mentioned at [1] AFAICT.
I think visual startup notification is significant.  Often enough I find error
notifications during startup which I can then track down and fix, and if this
information is hidden then startup errors might not get noticed.  :-/
[I do like that systemd can be loaded and you can choose when to turn it
on/off via passing 'init=/bin/systemd' to the booting kernel.  That and the
fast bootup time are nice.  Bootup time is not a significant benefit in my
case, as I'm using LUKS encryption with several long passwords to enter at
boot time.  :-P]
...

Post by Patrick Lauer
What we offer you is a modern, slim, userfriendly init system with
minimal dependencies. All you need is a C99 compiler and a posix sh!
The list of features is long and tedious
http://wiki.gentoo.org/wiki/OpenRC )

(Note to the reader: this is the same page as [1].)
Some feedback on the page above: in the first table comparing system startup
types there are markers for notes, e.g. "no[1]" concerning Read-Ahead, but the
expected note details after the table seem to be missing.

Post by Patrick Lauer
Should you decide to switch (or just evaluate if switching is possible /
makes sense) you'll get full support from us in migrating init scripts
and figuring out all the nontrivial changes. Just visit us on IRC (
meet us for a beer or two.

For others looking to evaulate:  at the tail end of [2] I found a link to the
OpenRC Git repository [3], along with more documentation on OpenRC and how to
migrate at [4].
[1] http://wiki.gentoo.org/wiki/OpenRC
[2] https://en.wikipedia.org/wiki/OpenRC
[3] http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git
[4] http://www.gentoo.org/proj/en/base/openrc/
 -- Chris
--
Chris Knadle
GPG Key: 4096R/0x1E759A726A9FDD74

--

--
Kind regards, Milan
--------------------------------------------------
Arvanta, http://www.arvanta.net
Please do not send me e-mail containing HTML code or documents in
proprietary format (word, excel, pps and so on)

[Chris Knadle]

Post by Matthias Klumpp
Hi!

:-) Greetings.

Post by Matthias Klumpp
AFAIK systemd supports startup notifications, even in colour - at
least it did this last time I tried (a few weeks ago)
Maybe your systemd version is too old?
(Quoting Lennart: "We now show the progress of fsck at boot on the
console, again. We also show the much loved colorful [ OK ] status
messages at boot again, as known from most SysV implementations.")
Regards,
Matthias

Thanks -- this let me know to look further into it.

The manpage for systemd explains a good bit of this.

The default of passing 'quiet' to the kernel is also apparently picked up by
systemd, which then suppresses the daemon startup messages. If 'quiet' is
removed, systemd gives colorized daemon startup messages, but this also makes
the kernel noisy.

The 'systemd.sysv_console=true' turns on on startup messages when the 'quiet'
option is used, however the startup messages don't seem to be the same as when
'quiet' is turned off, even when also passing 'systemd.log_color=true'. I'll
investigate this further when I don't have something more pressing to do.

-- Chris

--
Chris Knadle
***@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74

[Tollef Fog Heen]

]] Chris Knadle

Post by Chris Knadle
The default of passing 'quiet' to the kernel is also apparently picked
up by systemd, which then suppresses the daemon startup messages. If
'quiet' is removed, systemd gives colorized daemon startup messages,
but this also makes the kernel noisy.

I suspect you just want to use plymouth if you want startup messages and
don't want to get rid of quiet.

[Chris Knadle]

Post by Tollef Fog Heen
]] Chris Knadle

Post by Chris Knadle
The default of passing 'quiet' to the kernel is also apparently picked
up by systemd, which then suppresses the daemon startup messages. If
'quiet' is removed, systemd gives colorized daemon startup messages,
but this also makes the kernel noisy.

I suspect you just want to use plymouth if you want startup messages and
don't want to get rid of quiet.

I'm not looking for graphics or boot animation -- for instance I don't like
Ubuntu's default of graphical bootup, which from screenshots.debian.net seems
like it uses plymouth.

Specifically I'm looking to see the daemon startup console *text* messages,
but without verbose kernel bootup noise that is gotten if the 'quiet' option
is removed. Debian's default startup/init already does this, with ANSI color.
I'm looking to see if I can duplicate a similar appearance with systemd.

-- Chris

--
Chris Knadle
***@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74

[Michael Biebl]

Post by Chris Knadle
Specifically I'm looking to see the daemon startup console *text* messages,
but without verbose kernel bootup noise that is gotten if the 'quiet' option
is removed.

echo "kernel.printk = 3 4 1 3" > /etc/sysctl.d/no-kernel-messages.conf

[Chris Knadle]

Post by Michael Biebl

Post by Chris Knadle
Specifically I'm looking to see the daemon startup console *text*
messages, but without verbose kernel bootup noise that is gotten if the
'quiet' option is removed.

echo "kernel.printk = 3 4 1 3" > /etc/sysctl.d/no-kernel-messages.conf

No, this doesn't do what I want. The "kernel bootup noise" I'm talking about
are the verbose kernel bootup messages *before root is mounted*. sysctl
starts *after* root is mounted.

BTW the default /etc/sysctl.conf that comes with the Debian package contains a
commented-out version of the above "kernel.printk = 3 4 1 3 " already.

AFAICT I really want the 'quiet' linux command line parameter, and to
reconfigure the console output of systemd somehow.

-- Chris

--
Chris Knadle
***@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74

[Michael Biebl]

This is getting OT and a better question for debian-user, so this will
be my last post regarding this issue.

Post by Chris Knadle
AFAICT I really want the 'quiet' linux command line parameter, and to
reconfigure the console output of systemd somehow.

man 1 systemd :

Try adding "systemd.show_status=true systemd.sysv_console=true" to your
kernel command line. This is basically having the same effect for
systemd as removing the "quiet" kernel command line option.

[Chris Knadle]

Post by Michael Biebl
This is getting OT and a better question for debian-user, so this will
be my last post regarding this issue.

Agreed. Same.

Post by Michael Biebl

Post by Chris Knadle
AFAICT I really want the 'quiet' linux command line parameter, and to
reconfigure the console output of systemd somehow.

Try adding "systemd.show_status=true systemd.sysv_console=true" to your
kernel command line. This is basically having the same effect for
systemd as removing the "quiet" kernel command line option.

This combination does what I wanted. Thanks much.

Only thing I had missed was systemd.show_status=true because it wasn't clear
in the man page that this setting is also affected by 'quiet'.

-- Chris

--
Chris Knadle
***@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74

[Roger Leigh]

Post by Michael Biebl
This is getting OT and a better question for debian-user, so this will
be my last post regarding this issue.

Post by Chris Knadle
AFAICT I really want the 'quiet' linux command line parameter, and to
reconfigure the console output of systemd somehow.

Try adding "systemd.show_status=true systemd.sysv_console=true" to your
kernel command line. This is basically having the same effect for
systemd as removing the "quiet" kernel command line option.

Is this the default? Or do we need an additional "silent" option
so that systemd can behave similarly to the existing stuff when
passed the "quiet" option?


Roger

[Chris Knadle]

Post by Roger Leigh

Post by Michael Biebl
This is getting OT and a better question for debian-user, so this will
be my last post regarding this issue.

Post by Chris Knadle
AFAICT I really want the 'quiet' linux command line parameter, and to
reconfigure the console output of systemd somehow.

Try adding "systemd.show_status=true systemd.sysv_console=true" to your
kernel command line. This is basically having the same effect for
systemd as removing the "quiet" kernel command line option.

Is this the default?

? I'm having trouble figuring out what it would mean if I answered "no".

Post by Roger Leigh
Or do we need an additional "silent" option so that systemd can behave
similarly to the existing stuff when passed the "quiet" option?
Roger

I don't think a 'silent' option is required.



Grub defaults to passing 'quiet' to the kernel, and no systemd options.
Installing the systemd package does not change the options passed to the
kernel, and AFAIK cannot for Policy reasons.

When the 'quiet' option is passed to the kernel, systemd picks this up and
sets systemd.show_status=false and systemd.sysv_console=false. [The default
for both of these is 'true' if the 'quiet' option is not present.] The result
is that no daemon startup messages are sent to the console during bootup when
the 'quiet' option is used, unless these settings are chagned via passing the
additional kernel boot options described in the previous email above *after*
the 'quiet' option.

-- Chris

--
Chris Knadle
***@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74

[Tollef Fog Heen]

]] Chris Knadle

Post by Chris Knadle
Specifically I'm looking to see the daemon startup console *text* messages,
but without verbose kernel bootup noise that is gotten if the 'quiet' option
is removed. Debian's default startup/init already does this, with ANSI color.
I'm looking to see if I can duplicate a similar appearance with systemd.

(I see you've already gotten your reply, but adding this for
completeness)

Plymouth has a text mode too, just tell it to use the text theme.

[Michael Biebl]

Post by Chris Knadle
After testing systemd some, I've now grown a new appreciation for the default
Debian init system -- because it gives visual notification of what's been
started, where systemd does not.

Ahem, not true. I bet you are booting with the "quiet" kernel command
line argument. Remove that if you want to see the boot messages.