Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
RFC: OpenRC as Init System for Debian
156 views
Skip to first unread message
Patrick Lauer
Apr 25, 2012, 9:20:02 AM4/25/12
to
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 ( ope...@gentoo.org ) or
meet us for a beer or two.
Thanks for your consideration,
Patrick Lauer
Gentoo Developer, OpenRC co-maintainer
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4F97F3AB...@gentoo.org
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 ( ope...@gentoo.org ) or
meet us for a beer or two.
Thanks for your consideration,
Patrick Lauer
Gentoo Developer, OpenRC co-maintainer
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4F97F3AB...@gentoo.org
Arto Jantunen
Apr 25, 2012, 9:50:02 AM4/25/12
to
Patrick Lauer <pat...@gentoo.org> writes:
> 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
> 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.
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.
--
Arto Jantunen
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Patrick Lauer
Apr 25, 2012, 11:10:03 AM4/25/12
to
On 04/25/12 21:40, Arto Jantunen wrote:
[snip]
-> * 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")
> 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.
>
> 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 :)
> 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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4F980E8E...@gentoo.org
[snip]
>> 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
>> 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),
-> * 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")
> 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.
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.
>
> 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).
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 :)
> 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.
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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Igor Pashev
Apr 25, 2012, 11:40:01 AM4/25/12
to
I wonder no one mention Solaris SMF :-)
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Gergely Nagy
Apr 25, 2012, 12:00:03 PM4/25/12
to
Does a free port of that thing exist, which we could use?
--
|8]
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87fwbru...@algernon.balabit
--
|8]
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Holger Levsen
Apr 25, 2012, 12:30:02 PM4/25/12
to
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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201204251019...@layer-acht.org
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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Roger Leigh
Apr 25, 2012, 12:50:01 PM4/25/12
to
On Wed, Apr 25, 2012 at 08:52:59PM +0800, Patrick Lauer wrote:
> 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
> 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.
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
--
.''`. 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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Marco d'Itri
Apr 25, 2012, 1:50:02 PM4/25/12
to
On Apr 25, Patrick Lauer <pat...@gentoo.org> wrote:
> 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
> in the last months there have been many discussions about init systems,
> especially systemd. The current state seems to make no one really happy
does.
> 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.
make us waste more time.
> What we offer you is a modern, slim, userfriendly init system with
this one is not.
But I agree that it would have been nice 5 years ago.
--
ciao,
Marco
Svante Signell
Apr 25, 2012, 3:20:02 PM4/25/12
to
On Wed, 2012-04-25 at 19:49 +0200, Marco d'Itri wrote:
> On Apr 25, Patrick Lauer <pat...@gentoo.org> wrote:
>
...
> On Apr 25, Patrick Lauer <pat...@gentoo.org> wrote:
>
> > 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!
> > 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.
> > 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!
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Chow Loong Jin
Apr 25, 2012, 3:30:02 PM4/25/12
to
On 26/04/2012 03:05, Svante Signell wrote:
> On Wed, 2012-04-25 at 19:49 +0200, Marco d'Itri wrote:
>> On Apr 25, Patrick Lauer <pat...@gentoo.org> wrote:
>>
> ...
>>> 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!
>
>>> 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!
I think Arto Jantunen explained it pretty well earlier in this thread:
> On Wed, 2012-04-25 at 19:49 +0200, Marco d'Itri wrote:
>> On Apr 25, Patrick Lauer <pat...@gentoo.org> wrote:
>>
> ...
>>> 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!
>
>>> 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.
--
> 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.
Kind regards,
Loong Jin
Eray Aslan
Apr 26, 2012, 2:40:01 AM4/26/12
to
On Thu, Apr 26, 2012 at 03:23:18AM +0800, Chow Loong Jin wrote:
> I think Arto Jantunen explained it pretty well earlier in this thread:
> > 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
> I think Arto Jantunen explained it pretty well earlier in this thread:
> > 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
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.
--
Eray Aslan
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Arto Jantunen
Apr 26, 2012, 3:00:01 AM4/26/12
to
Eray Aslan <eray....@caf.com.tr> writes:
> On Thu, Apr 26, 2012 at 03:23:18AM +0800, Chow Loong Jin wrote:
>> I think Arto Jantunen explained it pretty well earlier in this thread:
>> > 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
> On Thu, Apr 26, 2012 at 03:23:18AM +0800, Chow Loong Jin wrote:
>> I think Arto Jantunen explained it pretty well earlier in this thread:
>> > 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.
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).
--
Arto Jantunen
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bernd Zeimetz
Apr 26, 2012, 3:50:01 AM4/26/12
to
On 04/26/2012 08:58 AM, Arto Jantunen wrote:
> Eray Aslan <eray....@caf.com.tr> writes:
>
>> On Thu, Apr 26, 2012 at 03:23:18AM +0800, Chow Loong Jin wrote:
>>> I think Arto Jantunen explained it pretty well earlier in this thread:
>>>> 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
> Eray Aslan <eray....@caf.com.tr> writes:
>
>> On Thu, Apr 26, 2012 at 03:23:18AM +0800, Chow Loong Jin wrote:
>>> I think Arto Jantunen explained it pretty well earlier in this thread:
>>>> 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).
top of that.
> 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).
>
--
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bernd Zeimetz
Apr 26, 2012, 3:50:02 AM4/26/12
to
On 04/25/2012 06:42 PM, Roger Leigh wrote:
> On Wed, Apr 25, 2012 at 08:52:59PM +0800, Patrick Lauer wrote:
>> 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
------------^^^^^
> On Wed, Apr 25, 2012 at 08:52:59PM +0800, Patrick Lauer wrote:
>> 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.
> 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 Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4F98FDFE...@bzed.de
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Josselin Mouette
Apr 26, 2012, 4:00:03 AM4/26/12
to
Le jeudi 26 avril 2012 à 09:47 +0200, Bernd Zeimetz a écrit :
> > 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
> > 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.
part of the required functionality, but so far it looks like vaporware.
--
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Goirand
Apr 26, 2012, 5:00:03 AM4/26/12
to
On 04/26/2012 12:19 AM, Holger Levsen wrote:
> 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.
> 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
>
>
>
I might see him tonight at the Shanghai LUG "hacking Thursday"! :)
Thomas
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Roger Leigh
Apr 26, 2012, 8:50:02 AM4/26/12
to
On Thu, Apr 26, 2012 at 09:49:18AM +0200, Bernd Zeimetz wrote:
> On 04/25/2012 06:42 PM, Roger Leigh wrote:
> > On Wed, Apr 25, 2012 at 08:52:59PM +0800, Patrick Lauer wrote:
> >> 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.
> On 04/25/2012 06:42 PM, Roger Leigh wrote:
> > On Wed, Apr 25, 2012 at 08:52:59PM +0800, Patrick Lauer wrote:
> >> 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.
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
--
.''`. 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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120426124...@codelibre.net
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Chris Knadle
Apr 26, 2012, 10:00:01 AM4/26/12
to
On Wednesday, April 25, 2012 08:52:59, Patrick Lauer wrote:
> 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
> 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).
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]
...
> 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 )
> minimal dependencies. All you need is a C99 compiler and a posix sh!
> The list of features is long and tedious
(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.
> 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 ( ope...@gentoo.org ) or
> meet us for a beer or two.
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
Chris....@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
Matthias Klumpp
Apr 26, 2012, 10:10:01 AM4/26/12
to
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
2012/4/26 Chris Knadle <Chris....@coredump.us>:
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
2012/4/26 Chris Knadle <Chris....@coredump.us>:
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAKNHny88JDFEpBJ0XCKw4JX6...@mail.gmail.com
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Michael Biebl
Apr 26, 2012, 10:30:01 AM4/26/12
to
On 26.04.2012 15:58, Chris Knadle wrote:
> 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
> 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.
line argument. Remove that if you want to see the boot messages.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Bernd Zeimetz
Apr 26, 2012, 10:30:02 AM4/26/12
to
On 04/26/2012 02:42 PM, Roger Leigh wrote:
[..]
something sane might be a good idea (yeah, I know that there would be a
painful transition...).
> 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
>
--
[..]
> 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
> be able to do this before we could adopt it.
something sane might be a good idea (yeah, I know that there would be a
painful transition...).
> 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 Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4F9959A9...@bzed.de
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Goirand
Apr 26, 2012, 12:00:03 PM4/26/12
to
On 04/26/2012 08:42 PM, Roger Leigh wrote:
> 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
> 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
>
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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Svante Signell
Apr 26, 2012, 1:10:02 PM4/26/12
to
On Thu, 2012-04-26 at 09:57 +0200, Josselin Mouette wrote:
> Le jeudi 26 avril 2012 à 09:47 +0200, Bernd Zeimetz a écrit :
> > > 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
> Le jeudi 26 avril 2012 à 09:47 +0200, Bernd Zeimetz a écrit :
> > > 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.
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",
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jon Dowland
Apr 26, 2012, 1:20:02 PM4/26/12
to
On Thu, Apr 26, 2012 at 07:05:55PM +0200, Svante Signell wrote:
> 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.
> 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!
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.)
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Josselin Mouette
Apr 26, 2012, 1:30:01 PM4/26/12
to
Le jeudi 26 avril 2012 à 19:05 +0200, Svante Signell a écrit :
> 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
> 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!
*only* about mounting USB devices. Mounting an USB device is such a
complicated action, one wonders how it can even work.
--
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1335461275.3615.664.camel@pi0307572
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jonathan McDowell
Apr 26, 2012, 1:30:02 PM4/26/12
to
On Thu, Apr 26, 2012 at 09:27:43AM +0300, Eray Aslan wrote:
> On Thu, Apr 26, 2012 at 03:23:18AM +0800, Chow Loong Jin wrote:
> > I think Arto Jantunen explained it pretty well earlier in this
> > thread:
> > > 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,
> On Thu, Apr 26, 2012 at 03:23:18AM +0800, Chow Loong Jin wrote:
> > I think Arto Jantunen explained it pretty well earlier in this
> > thread:
> > > 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.
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.
--
We are talking one charming motherf**king pig.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Milan P. Stanic
Apr 26, 2012, 2:00:03 PM4/26/12
to
On Thu, 2012-04-26 at 16:05, Matthias Klumpp wrote:
> 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
> Hi!
> AFAIK systemd supports startup notifications, even in colour - at
> least it did this last time I tried (a few weeks ago)
status (OK, Failed ...) are on the right end.
It would be better if the status are on the beginning of the line.
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)
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jonas Smedegaard
Apr 26, 2012, 2:20:01 PM4/26/12
to
On 12-04-26 at 10:23am, Jonathan McDowell wrote:
> On Thu, Apr 26, 2012 at 09:27:43AM +0300, Eray Aslan wrote:
> > On Thu, Apr 26, 2012 at 03:23:18AM +0800, Chow Loong Jin wrote:
> > > I think Arto Jantunen explained it pretty well earlier in this
> > > thread:
> > > > 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.
> On Thu, Apr 26, 2012 at 09:27:43AM +0300, Eray Aslan wrote:
> > On Thu, Apr 26, 2012 at 03:23:18AM +0800, Chow Loong Jin wrote:
> > > I think Arto Jantunen explained it pretty well earlier in this
> > > thread:
> > > > 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.
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
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
Ben Hutchings
Apr 26, 2012, 3:10:01 PM4/26/12
to
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.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Chris Knadle
Apr 26, 2012, 3:10:02 PM4/26/12
to
On Thursday, April 26, 2012 10:05:02, Matthias Klumpp wrote:
> Hi!
:-) Greetings.
> 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.
> Hi!
:-) Greetings.
> 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
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.
Adam Borowski
Apr 26, 2012, 4:00:02 PM4/26/12
to
On Thu, Apr 26, 2012 at 08:08:01PM +0100, Ben Hutchings wrote:
> On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote:
> > 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
> On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote:
> > 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.
chroots, vservers, etc.
No udev dependencies wrt handling real hardware are a waste of time, and
complicate stuff.
--
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets. Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.
Svante Signell
Apr 26, 2012, 4:30:02 PM4/26/12
to
On Thu, 2012-04-26 at 19:27 +0200, Josselin Mouette wrote:
> Le jeudi 26 avril 2012 à 19:05 +0200, Svante Signell a écrit :
> > 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!
> Le jeudi 26 avril 2012 à 19:05 +0200, Svante Signell a écrit :
> > 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.
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?
> Mounting an USB device is such a
> complicated action, one wonders how it can even work.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Petter Reinholdtsen
Apr 26, 2012, 4:30:01 PM4/26/12
to
[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
> to put in a usb stick _during_ the boot? We need to separate boot
> from adding/removing peripheral devices!
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. :)
--
Happy hacking
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Svante Signell
Apr 26, 2012, 4:40:02 PM4/26/12
to
On Thu, 2012-04-26 at 18:09 +0100, Jon Dowland wrote:
> On Thu, Apr 26, 2012 at 07:05:55PM +0200, Svante Signell wrote:
> > 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!
> On Thu, Apr 26, 2012 at 07:05:55PM +0200, Svante Signell wrote:
> > 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!
action whatsoever.
> 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.)
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Tollef Fog Heen
Apr 26, 2012, 4:50:01 PM4/26/12
to
]] 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.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87397q9...@qurzaw.varnish-software.com
> 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.
don't want to get rid of quiet.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Svante Signell
Apr 26, 2012, 4:50:02 PM4/26/12
to
On Thu, 2012-04-26 at 22:20 +0200, Petter Reinholdtsen wrote:
> [Svante Signell]
..
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 :-(
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1335472843.3...@hp.my.own.domain
> [Svante Signell]
..
> 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
> 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.
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 :-(
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ben Hutchings
Apr 26, 2012, 5:10:01 PM4/26/12
to
On Thu, Apr 26, 2012 at 10:40:43PM +0200, Svante Signell wrote:
> On Thu, 2012-04-26 at 22:20 +0200, Petter Reinholdtsen wrote:
> > [Svante Signell]
> ..
> > 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
> On Thu, 2012-04-26 at 22:20 +0200, Petter Reinholdtsen wrote:
> > [Svante Signell]
> ..
> > 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!
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.
> 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 :-(
you have more time to admire the boot process.
Or, you know, use udev and let it take care of persistent naming.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012042621...@decadent.org.uk
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Petter Reinholdtsen
Apr 26, 2012, 5:30:01 PM4/26/12
to
[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
> 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 :-(
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. :)
--
Happy hacking
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2flaa1y...@login1.uio.no
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Roger Leigh
Apr 26, 2012, 7:20:01 PM4/26/12
to
On Thu, Apr 26, 2012 at 11:50:51PM +0800, Thomas Goirand wrote:
> On 04/26/2012 08:42 PM, Roger Leigh wrote:
> > 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.
> On 04/26/2012 08:42 PM, Roger Leigh wrote:
> > 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
> but I'd be happy to discover it. Maybe I can start packaging with
> Patrick together, and with you as well.
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.
> 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)
- 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
}
> 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
> 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?
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.
> 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...
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
--
.''`. 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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120426230...@codelibre.net
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Russ Allbery
Apr 26, 2012, 8:10:01 PM4/26/12
to
Petter Reinholdtsen <pe...@hungry.com> writes:
> 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
> 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.
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.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Chris Knadle
Apr 26, 2012, 8:40:01 PM4/26/12
to
On Thursday, April 26, 2012 16:45:08, Tollef Fog Heen wrote:
> ]] 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
> ]] 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.
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.
Michael Biebl
Apr 26, 2012, 8:50:03 PM4/26/12
to
On 27.04.2012 02:29, Chris Knadle wrote:
> 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
> 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.
Patrick Lauer
Apr 26, 2012, 9:00:02 PM4/26/12
to
On 04/27/12 03:32, Adam Borowski wrote:
> On Thu, Apr 26, 2012 at 08:08:01PM +0100, Ben Hutchings wrote:
>> On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote:
>>> 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
> On Thu, Apr 26, 2012 at 08:08:01PM +0100, Ben Hutchings wrote:
>> On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote:
>>> 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.
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 :)
>
> 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.
>
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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Patrick Lauer
Apr 26, 2012, 9:10:01 PM4/26/12
to
On 04/27/12 08:02, Russ Allbery wrote:
> Petter Reinholdtsen <pe...@hungry.com> writes:
>
>> 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
> Petter Reinholdtsen <pe...@hungry.com> writes:
>
>> 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.
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.
>
> 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
> 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.
dangerous. It might work on a lightly loaded machine, most of the time.
It makes more sense to me to have meaningful return values :)
>
> These bugs are essentially unresolvable without something that understands
> kernel events
... udev/mdev/ /sys/kernel/uevent_helper to the rescue ...
> 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.
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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ben Hutchings
Apr 26, 2012, 9:30:01 PM4/26/12
to
On Fri, 2012-04-27 at 08:55 +0800, Patrick Lauer wrote:
> On 04/27/12 03:32, Adam Borowski wrote:
> > On Thu, Apr 26, 2012 at 08:08:01PM +0100, Ben Hutchings wrote:
> >> On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote:
> >>> 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))
[...]
> On 04/27/12 03:32, Adam Borowski wrote:
> > On Thu, Apr 26, 2012 at 08:08:01PM +0100, Ben Hutchings wrote:
> >> On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote:
> >>> 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.
--
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.
Russ Allbery
Apr 26, 2012, 10:00:01 PM4/26/12
to
Patrick Lauer <pat...@gentoo.org> writes:
> 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
> }
That's all nice and good from a syntax perspective, but we already have
> 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
> }
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.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87zk9yk...@windlord.stanford.edu
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Russell Coker
Apr 26, 2012, 10:20:01 PM4/26/12
to
On Fri, 27 Apr 2012, Svante Signell <svante....@telia.com> wrote:
> 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
> I've been struggling with eth0 and eth1 for some rime now, never knowing
> how it will be named for every new kernel :-(
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.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Russell Coker
Apr 26, 2012, 10:20:02 PM4/26/12
to
On Fri, 27 Apr 2012, Jon Dowland <jm...@debian.org> wrote:
> On Thu, Apr 26, 2012 at 07:05:55PM +0200, Svante Signell wrote:
> > 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
> On Thu, Apr 26, 2012 at 07:05:55PM +0200, Svante Signell wrote:
> > 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.
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.
> 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!
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.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201204271202....@coker.com.au
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Chris Knadle
Apr 26, 2012, 10:40:01 PM4/26/12
to
On Thursday, April 26, 2012 20:39:56, Michael Biebl wrote:
> On 27.04.2012 02:29, Chris Knadle wrote:
> > 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
> On 27.04.2012 02:29, Chris Knadle wrote:
> > 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
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.
Michael Biebl
Apr 26, 2012, 11:20:01 PM4/26/12
to
This is getting OT and a better question for debian-user, so this will
be my last post regarding this issue.
On 27.04.2012 04:34, Chris Knadle wrote:
> 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.
be my last post regarding this issue.
On 27.04.2012 04:34, Chris Knadle wrote:
> 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.
Chris Knadle
Apr 26, 2012, 11:50:01 PM4/26/12
to
On Thursday, April 26, 2012 23:18:35, Michael Biebl wrote:
> This is getting OT and a better question for debian-user, so this will
> be my last post regarding this issue.
Agreed. Same.
> This is getting OT and a better question for debian-user, so this will
> be my last post regarding this issue.
> On 27.04.2012 04:34, Chris Knadle wrote:
> > 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.
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'.
Tollef Fog Heen
Apr 27, 2012, 1:20:01 AM4/27/12
to
]] 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.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87vckl9...@qurzaw.varnish-software.com
> 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.
completeness)
Plymouth has a text mode too, just tell it to use the text theme.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Tollef Fog Heen
Apr 27, 2012, 1:30:02 AM4/27/12
to
]] 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.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
> 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.
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.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87obqd9...@qurzaw.varnish-software.com
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Goirand
Apr 27, 2012, 1:50:02 AM4/27/12
to
On 04/27/2012 10:02 AM, Russell Coker wrote:
> 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
> 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.
>
if the release team agrees...
Thomas
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Adrian Knoth
Apr 27, 2012, 3:00:01 AM4/27/12
to
On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote:
> 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
> 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).
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
--
mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bernd Zeimetz
Apr 27, 2012, 3:00:02 AM4/27/12
to
On 04/27/2012 07:39 AM, Thomas Goirand wrote:
> On 04/27/2012 10:02 AM, Russell Coker wrote:
>> 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?
> On 04/27/2012 10:02 AM, Russell Coker wrote:
>> 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...
--
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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bernd Zeimetz
Apr 27, 2012, 3:00:02 AM4/27/12
to
On 04/27/2012 02:02 AM, Russ Allbery wrote:
> Petter Reinholdtsen <pe...@hungry.com> writes:
>
>> 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
> Petter Reinholdtsen <pe...@hungry.com> writes:
>
>> 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.
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.
> 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.
>
--
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
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4F9A4315...@bzed.de
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Josselin Mouette
Apr 27, 2012, 4:00:01 AM4/27/12
to
Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit :
> > 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.
> 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.
--
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1335513264.3615.667.camel@pi0307572
> > 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.
> 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.
--
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Roger Leigh
Apr 27, 2012, 4:00:01 AM4/27/12
to
On Fri, Apr 27, 2012 at 05:18:35AM +0200, Michael Biebl wrote:
> This is getting OT and a better question for debian-user, so this will
> be my last post regarding this issue.
>
> On 27.04.2012 04:34, Chris Knadle wrote:
> > 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.
Is this the default? Or do we need an additional "silent" option
> This is getting OT and a better question for debian-user, so this will
> be my last post regarding this issue.
>
> On 27.04.2012 04:34, Chris Knadle wrote:
> > 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.
so that systemd can behave similarly to the existing stuff when
passed the "quiet" option?
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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120427075...@codelibre.net
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Patrick Lauer
Apr 27, 2012, 7:10:02 AM4/27/12
to
On 04/27/12 18:50, Martin Wuertele wrote:
> * Josselin Mouette <jo...@debian.org> [2012-04-27 09:53]:
> 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 ...
>
> Could you enlighten me please.
>
> Kind regards,
> Martin
> * Josselin Mouette <jo...@debian.org> [2012-04-27 09:53]:
>
>> Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit :
>>>> 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
>> Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit :
>>>> 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.
>
> 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 ...
>
> Could you enlighten me please.
>
> Kind regards,
> Martin
>
>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4F9A7E1F...@gentoo.org
>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Martin Wuertele
Apr 27, 2012, 7:10:02 AM4/27/12
to
> Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit :
> > > 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.
> > > 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.
results in the requirement for an event based boot process.
Could you enlighten me please.
Kind regards,
Martin
Kind regards,
Martin
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120427105...@anguilla.debian.or.at
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jon Dowland
Apr 27, 2012, 7:20:01 AM4/27/12
to
On Fri, Apr 27, 2012 at 12:12:00PM +1000, Russell Coker wrote:
> 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
> 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.
interface to get eth0 (identified by MAC address) gets eth0 afterwards, no
matter what order things come up.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Svante Signell
Apr 27, 2012, 10:30:01 AM4/27/12
to
On Fri, 2012-04-27 at 09:54 +0200, Josselin Mouette wrote:
> Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit :
...
> Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit :
> 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
> 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.
polite!
> > 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.
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?
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Svante Signell
Apr 27, 2012, 10:40:03 AM4/27/12
to
On Fri, 2012-04-27 at 16:29 +0200, Svante Signell wrote:
> On Fri, 2012-04-27 at 09:54 +0200, Josselin Mouette wrote:
> > > 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
> On Fri, 2012-04-27 at 09:54 +0200, Josselin Mouette wrote:
> > > 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.
used, but with init scripts used for boot.
> 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?
a pity for people who don't want it.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Chris Knadle
Apr 27, 2012, 1:20:01 PM4/27/12
to
On Friday, April 27, 2012 03:54:51, Roger Leigh wrote:
> On Fri, Apr 27, 2012 at 05:18:35AM +0200, Michael Biebl wrote:
> > This is getting OT and a better question for debian-user, so this will
> > be my last post regarding this issue.
> >
> > On 27.04.2012 04:34, Chris Knadle wrote:
> > > 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.
>
> Is this the default?
? I'm having trouble figuring out what it would mean if I answered "no".
> On Fri, Apr 27, 2012 at 05:18:35AM +0200, Michael Biebl wrote:
> > This is getting OT and a better question for debian-user, so this will
> > be my last post regarding this issue.
> >
> > On 27.04.2012 04:34, Chris Knadle wrote:
> > > 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.
>
> 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
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.
Tollef Fog Heen
Apr 27, 2012, 1:40:02 PM4/27/12
to
]] Martin Wuertele
> * Josselin Mouette <jo...@debian.org> [2012-04-27 09:53]:
>
> > Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit :
> > > > 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.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
> * Josselin Mouette <jo...@debian.org> [2012-04-27 09:53]:
>
> > Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit :
> > > > 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.
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.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87haw58...@qurzaw.varnish-software.com
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Vincent Bernat
Apr 27, 2012, 8:30:01 PM4/27/12
to
OoO Vers la fin de l'après-midi du vendredi 27 avril 2012, vers 16:29,
Svante Signell <svante....@telia.com> disait :
> 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.
--
Vincent Bernat ☯ http://vincent.bernat.im
Don't stop at one bug.
- The Elements of Programming Style (Kernighan & Plauger)
Svante Signell <svante....@telia.com> disait :
> 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?
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.
--
Vincent Bernat ☯ http://vincent.bernat.im
Don't stop at one bug.
- The Elements of Programming Style (Kernighan & Plauger)
Ritesh Raj Sarraf
Apr 28, 2012, 4:20:01 AM4/28/12
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Friday 27 April 2012 02:10 AM, Svante Signell wrote:
>> 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
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCgAGBQJPm6dhAAoJEKY6WKPy4XVpJ4gP/28MSVaq/FcxGzYLZG3U3cog
RvSIv1RcVQfB0N/HuTKSzP19Y0XTPhq7DxJlFwz0c9MgPaUn+W2YngK05XFCGf/S
+zic5zf62pDQymjZ+5M6w+puuzJmbdFYEZdJULBn2e0MzX3b8rZyZulutK5UgMdn
n1W51h2Uq6PpYAE4VQ4WqD/Jo+Bbk3D5f8wy7C38yRPEPSaXNW5seLEU8B2xfQGR
suShUT+06z/BwYLzImKis+vlj8UWYD08h4mLirQt1722w3OU21EMVGDz7+HXIqxe
G4Mggz7wuv7IlxhvxSUitpb3AWHl5Mnnc4vQ+yOKHSHcJsLgOZSfi/ugqHi1YvMm
wTUwqnaEdTPq8cSY78zUJsw+JPmDt7NDmwvL0oWDCvNzwQg5MAxFPFIdLBdznnoT
Wi6Tvse5NheLFgRxUQj+aCtRYAf4FMY6GtVf46IJaeAyrONYPvV7VRA8JOw82wRw
pDirFZjrl/DzXot5LvAbdNpRvOhSFFk6dCoIYVlYvYoBPaNupPC35AvI/waQKseu
eobR/fG7PjwsqQlTr2oiXuh8Oj4ideaNGbdvlVFSh2DBGTEqRZ8EQ0Bkk535d3S2
YkOwHm3lmvAaTD+2SP6A2XHmlvliQC1bDrRvNgFFqRtrVJKk1yQOt3Cu2GZltsOr
dotNNUSr+OST1sBfAZCW
=oGRb
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4F9BA762...@researchut.com
Hash: SHA512
On Friday 27 April 2012 02:10 AM, Svante Signell wrote:
>> 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.
> 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
> named for every new kernel :-(
>
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCgAGBQJPm6dhAAoJEKY6WKPy4XVpJ4gP/28MSVaq/FcxGzYLZG3U3cog
RvSIv1RcVQfB0N/HuTKSzP19Y0XTPhq7DxJlFwz0c9MgPaUn+W2YngK05XFCGf/S
+zic5zf62pDQymjZ+5M6w+puuzJmbdFYEZdJULBn2e0MzX3b8rZyZulutK5UgMdn
n1W51h2Uq6PpYAE4VQ4WqD/Jo+Bbk3D5f8wy7C38yRPEPSaXNW5seLEU8B2xfQGR
suShUT+06z/BwYLzImKis+vlj8UWYD08h4mLirQt1722w3OU21EMVGDz7+HXIqxe
G4Mggz7wuv7IlxhvxSUitpb3AWHl5Mnnc4vQ+yOKHSHcJsLgOZSfi/ugqHi1YvMm
wTUwqnaEdTPq8cSY78zUJsw+JPmDt7NDmwvL0oWDCvNzwQg5MAxFPFIdLBdznnoT
Wi6Tvse5NheLFgRxUQj+aCtRYAf4FMY6GtVf46IJaeAyrONYPvV7VRA8JOw82wRw
pDirFZjrl/DzXot5LvAbdNpRvOhSFFk6dCoIYVlYvYoBPaNupPC35AvI/waQKseu
eobR/fG7PjwsqQlTr2oiXuh8Oj4ideaNGbdvlVFSh2DBGTEqRZ8EQ0Bkk535d3S2
YkOwHm3lmvAaTD+2SP6A2XHmlvliQC1bDrRvNgFFqRtrVJKk1yQOt3Cu2GZltsOr
dotNNUSr+OST1sBfAZCW
=oGRb
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Goirand
Apr 28, 2012, 2:00:02 PM4/28/12
to
On 04/28/2012 08:29 AM, Vincent Bernat wrote:
> 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
> 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.
>
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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Svante Signell
Apr 29, 2012, 5:30:02 AM4/29/12
to
On Sat, 2012-04-28 at 02:29 +0200, Vincent Bernat wrote:
> OoO Vers la fin de l'après-midi du vendredi 27 avril 2012, vers 16:29,
> Svante Signell <svante....@telia.com> disait :
>
> > 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
> OoO Vers la fin de l'après-midi du vendredi 27 avril 2012, vers 16:29,
> Svante Signell <svante....@telia.com> disait :
>
> > 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".
_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.
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.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bernd Zeimetz
Apr 29, 2012, 9:00:02 AM4/29/12
to
On 04/27/2012 07:33 PM, Tollef Fog Heen wrote:
> ]] Martin Wuertele
>
>> * Josselin Mouette <jo...@debian.org> [2012-04-27 09:53]:
>>
>>> Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit :
>>>>> 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
> ]] Martin Wuertele
>
>> * Josselin Mouette <jo...@debian.org> [2012-04-27 09:53]:
>>
>>> Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit :
>>>>> 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.
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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4F9D3909...@bzed.de
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bernd Zeimetz
Apr 29, 2012, 9:10:01 AM4/29/12
to
On 04/27/2012 03:28 AM, Ben Hutchings wrote:
> On Fri, 2012-04-27 at 08:55 +0800, Patrick Lauer wrote:
>> On 04/27/12 03:32, Adam Borowski wrote:
>>>>
>>>> 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.
--
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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4F9D3B4F...@bzed.de
> On Fri, 2012-04-27 at 08:55 +0800, Patrick Lauer wrote:
>> On 04/27/12 03:32, Adam Borowski wrote:
>>> On Thu, Apr 26, 2012 at 08:08:01PM +0100, Ben Hutchings wrote:
>>>> On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote:
>>>>> 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.
>>>> On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote:
>>>>> 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).
>>>>
>>>>
>>>> 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.
--
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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Miles Bader
Apr 29, 2012, 9:50:01 AM4/29/12
to
Svante Signell <svante....@telia.com> writes:
> 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
> 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.
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
--
Philosophy, n. A route of many roads leading from nowhere to nothing.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Miles Bader
Apr 29, 2012, 10:20:02 AM4/29/12
to
Stephan Seitz <stse+...@fsing.rootsland.net> writes:
>>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?
>>Isn't mounting filesystems, which can depend on the network, part of
>>the boot process?
>
> - 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
--
Inhumanity, n. One of the signal and characteristic qualities of humanity.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ben Hutchings
Apr 29, 2012, 10:20:01 AM4/29/12
to
On Sun, 2012-04-29 at 14:59 +0200, Bernd Zeimetz wrote:
> On 04/27/2012 03:28 AM, Ben Hutchings wrote:
> > On Fri, 2012-04-27 at 08:55 +0800, Patrick Lauer wrote:
> >> On 04/27/12 03:32, Adam Borowski wrote:
> >>> On Thu, Apr 26, 2012 at 08:08:01PM +0100, Ben Hutchings wrote:
> >>>> On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote:
> >>>>> 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
> On 04/27/2012 03:28 AM, Ben Hutchings wrote:
> > On Fri, 2012-04-27 at 08:55 +0800, Patrick Lauer wrote:
> >> On 04/27/12 03:32, Adam Borowski wrote:
> >>> On Thu, Apr 26, 2012 at 08:08:01PM +0100, Ben Hutchings wrote:
> >>>> On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote:
> >>>>> 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.
alternate components.
Ben.
--
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.
Bernd Zeimetz
Apr 29, 2012, 10:30:02 AM4/29/12
to
There is no reason why we should not allow people to use mdev or whatever they
like instead of udev.
--
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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4F9D4FAF...@bzed.de
--
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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bernd Zeimetz
Apr 29, 2012, 10:40:02 AM4/29/12
to
On 04/29/2012 04:18 PM, Miles Bader wrote:
> Stephan Seitz <stse+...@fsing.rootsland.net> writes:
>>> 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
> Stephan Seitz <stse+...@fsing.rootsland.net> writes:
>>> 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...
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.
--
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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4F9D5093...@bzed.de
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Vincent Bernat
Apr 29, 2012, 12:30:01 PM4/29/12
to
OoO En cette fin de matinée radieuse du dimanche 29 avril 2012, vers
11:25, Svante Signell <svante....@telia.com> disait :
>> 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.
>> 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?
Format a program to help the reader understand it.
11:25, Svante Signell <svante....@telia.com> disait :
>> 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.
is through this 3G usb dongle. If it does not happen on boot, it never
happens.
>> 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.
between system daemons? Isn't the job of init?
Format a program to help the reader understand it.
Vincent Bernat
Apr 29, 2012, 12:40:01 PM4/29/12
to
OoO Pendant le repas du samedi 28 avril 2012, vers 19:54, Thomas Goirand
<zi...@debian.org> disait :
>> 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.
Make sure special cases are truly special.
<zi...@debian.org> disait :
>> 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.
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.
Make sure special cases are truly special.
Roger Leigh
Apr 29, 2012, 1:50:01 PM4/29/12
to
On Fri, Apr 27, 2012 at 08:49:24AM +0200, Adrian Knoth wrote:
> On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote:
>
> > 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).
>
> And then, there is this statement about the core distro:
> On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote:
>
> > 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
--
.''`. 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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120429174...@codelibre.net
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Roger Leigh
Apr 29, 2012, 2:00:02 PM4/29/12
to
On Thu, Apr 26, 2012 at 01:42:48PM +0100, Roger Leigh wrote:
> 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
--
.''`. 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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120429175...@codelibre.net
> 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
--
.''`. 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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Steve Langasek
Apr 29, 2012, 2:20:02 PM4/29/12
to
On Sun, Apr 29, 2012 at 03:59:03PM +0200, Stephan Seitz wrote:
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/
> 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.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120429180...@virgil.dodds.net
> On Sun, Apr 29, 2012 at 10:33:16PM +0900, Miles Bader wrote:
> >Isn't mounting filesystems, which can depend on the network, part of
> >the boot process?
> >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
> - 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?
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/
> 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.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Svante Signell
Apr 29, 2012, 3:10:02 PM4/29/12
to
On Sun, 2012-04-29 at 20:19 +0200, Marco d'Itri wrote:
> 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.
> > 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?
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1335726410.1819.97.camel@x60
> On Apr 29, Roger Leigh <rle...@codelibre.net> wrote:
>
> > 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
>
> > I hope I'm not alone in feeling quite uneasy about the implications
> > of the above.
> 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.
> > 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
> direction for Debian, nor is NIH a great argument in software design.
Talking about NIH, is systemd not that if anything?
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Marco d'Itri
Apr 29, 2012, 3:10:02 PM4/29/12
to
> I hope I'm not alone in feeling quite uneasy about the implications
> of the above.
> 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.
Red Hat maintains most Linux core components and we do not, there is not
much we can do about it.
> 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
> 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.
--
direction for Debian, nor is NIH a great argument in software design.
ciao,
Marco
Fernando Lemos
Apr 29, 2012, 3:30:02 PM4/29/12
to
On Sun, Apr 29, 2012 at 2:45 PM, Roger Leigh <rle...@codelibre.net> wrote:
> 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
> 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.
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.
> 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.
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.
> 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?
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,
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jonathan Nieder
Apr 29, 2012, 3:40:02 PM4/29/12
to
Marco d'Itri wrote:
> 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
> 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.
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.)
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Roger Leigh
Apr 29, 2012, 4:20:01 PM4/29/12
to
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
--
.''`. 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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Fernando Lemos
Apr 29, 2012, 5:00:01 PM4/29/12
to
On Sun, Apr 29, 2012 at 5:14 PM, Roger Leigh <rle...@codelibre.net> wrote:
> 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
> 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.
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,
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Uoti Urpala
Apr 29, 2012, 5:30:01 PM4/29/12
to
Roger Leigh wrote:
> 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
> 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
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.
> 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,
> 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 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".
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Marco d'Itri
Apr 29, 2012, 5:30:02 PM4/29/12
to
On Apr 29, Jonathan Nieder <jrni...@gmail.com> wrote:
> 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
> Red Hat employs some eminently friendly and reasonable people.
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)
> Claiming that we are at their mercy is ignoring the ability to reason
> with them.
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.
--
ciao,
Marco
Uoti Urpala
Apr 29, 2012, 7:10:01 PM4/29/12
to
Marco d'Itri wrote:
> 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.
> 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
> to work around the inferior configuration files handling of RPM
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.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Miles Bader
Apr 29, 2012, 11:40:01 PM4/29/12
to
Bernd Zeimetz <be...@bzed.de> writes:
>> 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
>> 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.
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
--
gravity a demanding master ... soft soft snow
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Tollef Fog Heen
Apr 30, 2012, 1:40:01 AM4/30/12
to
]] 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?
> 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.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87aa1t7...@qurzaw.varnish-software.com
> 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.
the right place. And why would you stop networking because the link
flaps?
> If you want to do something after your devices appear, use udev.
services starting, it shouldn't run init script and such itself.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jonathan Nieder
Apr 30, 2012, 2:50:02 AM4/30/12
to
Marco d'Itri wrote:
> 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)
Thanks for explaining. Very interesting examples.
> 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)
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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Dmitry Nezhevenko
Apr 30, 2012, 4:50:02 AM4/30/12
to
On Mon, Apr 30, 2012 at 01:49:57AM +0300, Uoti Urpala wrote:
> Marco d'Itri wrote:
> > 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
> Marco d'Itri wrote:
> > 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
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...
--
WBR, Dmitry
Uoti Urpala
Apr 30, 2012, 8:10:01 AM4/30/12
to
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.
> With "etc-overrides-lib" it's not possible at all...
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).
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Dmitry Nezhevenko
Apr 30, 2012, 8:40:02 AM4/30/12
to
On Mon, Apr 30, 2012 at 02:44:42PM +0300, Uoti Urpala wrote:
> > 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
> > 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.
("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.
> > 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).
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
Steve McIntyre
Apr 30, 2012, 8:50:02 AM4/30/12
to
that *will* support what we want/need rather than simply meekly
following.
--
Steve McIntyre, Cambridge, UK. st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jon Dowland
Apr 30, 2012, 9:40:02 AM4/30/12
to
On Fri, Apr 27, 2012 at 08:56:21AM +0200, Bernd Zeimetz wrote:
> 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.
I can't see another way to solve this problem, other than definine more than
one network state, and making sure the dependencies are to the correct ones
(e.g. "post-vpn", or "gateway-available", or whatever)
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120430133821.GH7795@debian
> 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.
I can't see another way to solve this problem, other than definine more than
one network state, and making sure the dependencies are to the correct ones
(e.g. "post-vpn", or "gateway-available", or whatever)
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
It is loading more messages.
0 new messages