On 9/13/07, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
On 9/13/07, Jon Nettleton <jon.nettleton(a)gmail.com> wrote:
> I tentatively have a working config. I added N as another runlevel
> that chkconfig can turn on and off. The problem is that the scripts
> are slightly different for NMDispatcher than standard init. I am
> starting to lean more towards having another tab in
> system-config-services that manages them like xinetd. I am open to
> suggestions though.
exposing NMDispatcher controlled services like xinetd is handled now
is probably fine.
Here's the next question.
How do you add more services to NMDispatcher's control? From a
packager's perspective what do I have to do to ship a package with a
network based service script? Am I going to have to ship two different
versions of the script? One for the legacy network system and another
for the NMDispatcher?
Sure now you start answering the hard questions. Well the scripts I
use are all based around the same generic dispatcher.d script. The
only variance is whether you check in /var/lock/subsys or /var/run to
figure out if the daemon is always running. Other than that they just
run service NAMEOFSERVICE on/off/restart. If we could standardize and
put all our lock files or pid files in a single place then we could
run a single script from dispatcher.d that wraps symlinks put in
/etc/rc.d/rcN.d/ and does the appropriate thing to the service.
hmmm, that is confusing.
/etc/NetworkManager/dispatcher.d/network-services
on interface up it loops through
/etc/rc.d/rcN.d/S(*) and either service $1 start or service $1
restart depending whether
/var/run/$1 exists or not.
Now that I look at it like that does it make sense to make
network-services an actual init-script that is responsible for for
/etc/rc.d/rcN.d/
If we are running NetworkManager it is activated through dispatcher.d,
otherwise we just enable it in standard init after network.
I think that should work.
Jon