Erich Schubert wrote: >Hi, > > >>>Hmm... that would be an option to solve communication, too - the core >>>parts all retain a fd to talk to the main init process, the launchers >>>close that fd for the actual daemons. >>>If we find a configuration format (shell scripts are difficult then) >>>that can deal with the fd, that would be nice. >>> >>> >>> >>Could you give me an example? Not 100% sure I understand how you mean. >> >> > >fd 0 = stdin >fd 1 = stdout >fd 2 = stderr >fd 3 = to init >fd 4 = from init > >Before a launch helper execs the real daemon, it closes fd 3 and 4. >If it's e.g. a monitor and not a launch helper (e.g. a "runlevel" >manager or the dbus connector) it will keep these fds open, and >recieve notices from init on fd 4, and send commands to it on fd 3. > > And say you want to monitor all output from all daemons? I like a event/hook based system where plugins/programs can hook into events much better than every service having to specifically say "you use this".
>best regards, >Erich Schubert >-- > erich@(mucl.de|debian.org) -- GPG Key ID: 4B3A135C (o_ > To understand recursion you first need to understand recursion. //\ > Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für V_/_ > eine Stunde wie eine Heimat aus. --- Herrmann Hesse > >_______________________________________________ >initscripts-ng-devel mailing list >[email protected] >http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel > > > _______________________________________________ initscripts-ng-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
