Re: RFC: OpenRC as Init System for Debian
On Thu, May 03, 2012 at 08:54:11AM +0800, Patrick Lauer wrote:
> On 05/03/12 02:16, Michael Biebl wrote:
> > On 02.05.2012 19:05, Martin Wuertele wrote:
> >> I don't think this is a better example. Actually I think this is an
> >> example where udev/mdev could launch/stop bluetoothd.
> > Long running daemons should *not* be started by udev. udev is *not* a
> > service manager.
> > What udev should do is signal the init system that the device is
> > available and the init system will start and manage the daemon. That's
> > what systemd and upstart do.
> >
> So, this whole sub-thread boils down to this:
>
> "Our current init scripts don't handle dependencies properly"
>
> Once you fix that you can just let udev trigger /etc/init.d/bluetooth
> start, and that will do all the needed magic properly.
>
> ... and OpenRC has been doing that for such a long time that I find it
> hard to understand that people are still not using it ;)
>
> I'm still slightly confused what people mean with "event based", I think
> there are at least three similar, but distinct definitions going around.
> A good part of that is already handled by the device manager, and the
> rest appears to be user actions - if someone can find me a good example
> of an event that doesn't fit into these categories I might understand
> why from my point of view people seem to be violently agreeing so hard.
So, what you're saying is that we should fork udev to do things that
neither its upstream developer nor its Debian maintainer doesn't intend
for it to do, all to make it possible to use an init-system that doesn't
support events, instead of using an event based system that's designed
to work with udev?
Yeah, makes perfect sense...
Regards: David
--
/) David Weinehall <tao@debian.org> /) Rime on my window (\
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/
Reply to: