[Mono-list] System.ServiceProcess.ServiceBase

A Rafael D Teixeira rafaelteixeirabr@hotmail.com
Wed, 09 Apr 2003 11:07:52 -0300

>From: Mark Derricutt <mark@talios.com>

>If it compiles fine, it should suffice for what we currently need ( with
>it still running on a windows host ).  I'll take a look a the services
>stuff in cvs, not sure if I'll be much use thou, so far I'm only a week or
>two into really using C# :)

I've made minimal stubbing, so just pointing non-stubbed parts you need is 
of some help. Testing implementation, when done, is also helpfull, so please 
don't think you can't help. Thanks for any help!

>What sort of services framework do we want to provide to mono/linux?  We
>were discussing this in the office this afternoon, possibly implement the
>ServiceBase class to provide base functionality that'll fork and daemonize
>itself, and handle ( pass over to the implementing subclass ) the
>appropriate start/stop/restart messages ( kill -HUP or process.exe
>--restart style ).

Sure that is one way of doing things, but my proposal is to have a single 
daemon (I'm calling it 'monod') starting/tracking/managing all mono 
services. Somewhat similar to services.exe in Win2000, that manages 
services, each one started in a svchost.exe process.

The monod daemon would be started in the SysV style. But each service would 
be started on a dedicated process created by monod (no need to fork itself).

The advantages of this approach are:

- Services configuration semantics (start on boot, start on-demand, start 
manually) are more easily mapped to any platform. The Linux way would demand 
coordinating rc files/directories with inetd/xinetd. Also inetd only can 
start services on demand if they listen a tcp port, what isn't always the 
case (I'm surely not a Linux expert, so I may be wrong here)

- A GUI for starting/stopping services is easier to construct by talking 
directly to monod than having to read/interpret scattered files (etc/conf, 
PIDs, etc...)

- Pausing/restarting services could be faster. It obviously depends on the 
chosen communication channel between monod and the services, but we need a 
fast one anyway.

- Security settings (impersonation issues specially), would be easier to map 
and control, and would behave more like .net security.

And so the list would go on...

Hey, people in the list, what are your thoughts?

Happy hackings,
Rafael Teixeira
Brazilian Polymath
Mono, MonoQLE Hacker

STOP MORE SPAM with the new MSN 8 and get 2 months FREE*