On Fri, 2007-09-14 at 17:15 -0400, Matthias Clasen wrote:
On Fri, 2007-09-14 at 23:11 +0200, Nils Philippsen wrote:
> Now what I really don't want to do is deal with service type transitions
> (NMD gets stopped -> network-based services get normal SysVinit services
> again) as I don't see real value behind it. If network-based services
> need a daemon to run properly then it better ran. It's not really a new
> situation -- if xinetd doesn't run, xinetd-based services don't get
> started. Just as with every other basic building block of the system.
> Makes sense?
As long as it will be able to support both traditional networking setups
(for servers) and NM-based setups, it should be fine.
That should be possible, as long as s-c-services can properly
distinguish between the two types -- at the moment everything
in /etc/init.d is treated as a SysVinit service. As I understand it,
"on-demand" or "event-triggered" services, and whatever they're
that's what these "network-based" services are, shall be started through
dbus in the long run. I don't think adding kludges in s-c-services to
support an artificial runlevel "N" for that is a good thing to do.
I don't think
going back and forth between these two at runtime is very interesting.
No. Actually I think that one service can be startable through both
SysVinit and on-demand by dbus and s-c-services should in that case
offer control over both types. It might be a bit tricky to do UI wise,
but I think this nut is crackable ;-).
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011