[Opensim-dev] Feature Request ...
Kyle Hamilton
aerowolf at gmail.com
Sun Dec 21 11:02:03 UTC 2008
Then, with all respect, this is where new development should occur.
Windows systems have the ability to auto log-on with a username and
password. Since the threat model that the project is working with
right now does not involve local attacks, it's fairly reasonable to
not implement a Service wrapper. If you need it, build it. (And,
honestly, since the Service mechanism is Windows-only, it should
properly be viewed as Microsoft.Win32.ServiceBase, not
System.ServiceBase -- no matter what name you use to call it, it's
Windows-only.)
There is no System.ServiceProcess class in mono, so any attempt to use
it does need to be in a separate assembly, one that isn't built with
the Mono profile from nant.
http://msdn.microsoft.com/en-us/library/ms173139.aspx has information
on how to load an assembly into a different AppDomain than the current
one; I'm finding it difficult to figure out from their documentation
what you should use to load it into the current AppDomain and
instantiate a particular class from it.
I think it's something like:
using System;
using System.Reflection;
// First load the assembly
System.Reflection.Assembly OpenSimGridServer =
LoadFrom("OpenSim.Grid.GridServer.exe");
// Instantiate the requested class. The argument must be a String.
// It returns an Object which can be coerced to the proper Type.
Object OpenSimGridServer.CreateInstance("OpenSim.GridServer.GridServerBase");
http://msdn.microsoft.com/en-us/library/system.serviceprocess.aspx has
more information on ServiceProcess -- your service process must set
its state properly in OnStart (STOPPED at first, START_PENDING when
the Start command is received, during which it must create a new
thread and instantiate the GridServer class within it, RUNNING after
it's started), and handle the state properly in OnStop (STOP_PENDING
when it first receives it, STOPPED after the thread ends).
Stefan, I'd recommend you look at that page (the ServiceProcess
documentation) to see what you're doing wrong in your production code
(which doesn't start a new thread, and can't handle anything other
than Start).
-Kyle H
On Sun, Dec 21, 2008 at 12:59 AM, Lc <lcc1967 at gmail.com> wrote:
> some functions are not in xmlrpc and i'm not sure the one implemented are
> fully functional anyway (ie terrain related, control login and such)
>
> On Sun, Dec 21, 2008 at 9:54 AM, Kyle Hamilton <aerowolf at gmail.com> wrote:
>>
>> There is no access to a console in service mode. This is part of why
>> the xmlrpc admin stuff exists.
>>
>> Logging can be configured to go to a file instead of the console.
>>
>> Dumping is handled by the OS, and if it does dump the service manager
>> will automatically restart it.
>>
>> -Kyle H
>>
>> On Sun, Dec 21, 2008 at 12:50 AM, Lc <lcc1967 at gmail.com> wrote:
>> > Before doing this kind of cooking, better spending time to make the
>> > system
>> > usable.
>> > Questions:
>> > how the user will access to the console in your service mode ?
>> > how could he see any errors / dump ?
>> > SM
>> >
>> > On Sun, Dec 21, 2008 at 8:31 AM, Develope <Develope at ashuan.de> wrote:
>> >>
>> >> Hi,
>> >>
>> >> thank you for answering so fast ...
>> >>
>> >> @Kyle Hamilton
>> >> 1. You can also use srvany.exe from Microsoft to turn any .exe into a
>> >> service. http://www.iopus.com/guides/srvany.htm has information.
>> >>
>> >> --- If you do that, you are not able to control your service like
>> >> OnStart(). The Memoryallocation in "real" Services (ServiceBase) is
>> >> much
>> >> faster than them doing under srvany. There are many other drawbacks
>> >> using srvany.exe (Logging, dependencies, rightsmanagement, installation
>> >> ...)
>> >>
>> >> @ Stefan Andersson
>> >> 2) To be able to do so, you should implement the services as
>> >> 'wrappers',
>> >> separate applications that _use_ the Main Classes, not change or expand
>> >> on them, like for example for the grid service wrapper:
>> >>
>> >> partial class GridServ : ServiceBase
>> >> {
>> >> private GridServerBase m_gridApplication;
>> >>
>> >> protected override void OnStart(string[] args)
>> >> {
>> >> // Define working directory (For a service, this is set to
>> >> System dir by default...)
>> >> Process pc = Process.GetCurrentProcess();
>> >> string useDirectory = pc.MainModule.FileName.Substring(0,
>> >> pc.MainModule.FileName.LastIndexOf(@"\"));
>> >> Directory.SetCurrentDirectory(useDirectory);
>> >> log4net.Config.XmlConfigurator.Configure();
>> >> m_gridApplication = new GridServerBase();
>> >> m_gridApplication.Startup();
>> >> }
>> >> }
>> >>
>> >> (This snippet taken from Tribal Medias proprietary service wrappers -
>> >> feel free to copy+paste.)
>> >>
>> >> --- It is impossible to not change the main applications, cause
>> >> they
>> >> all went into
>> >> public void Work()
>> >> {
>> >> m_console.Notice("Enter help for a list of commands\n");
>> >>
>> >> while (true)
>> >> {
>> >> m_console.Prompt();
>> >> }
>> >> }
>> >>
>> >> Holding a Service into a loop or in console.readline make the
>> >> OnStart() not responsable for the machine and nothing runs.
>> >>
>> >> --- Is the System.ServiceProcess not implemented in Mono ? If so there
>> >> is no problem doing this. In my solution all executables are running as
>> >> service and doing well (Win 2003). I try to evaluate how it works in
>> >> mono.
>> >>
>> >> --- My implementation is:
>> >> Here is the first bad hack
>> >> public /*abstract*/ class BaseOpenSimServer :
>> >> System.ServiceProcess.ServiceBase
>> >> {
>> >> ...
>> >> public static void RunService(BaseOpenSimServer
>> >> pInstance, string[] args)
>> >> {
>> >> ...
>> >> }
>> >> ...
>> >> }
>> >>
>> >> In case of Gridserver ...
>> >> public static void Main(string[] args)
>> >> {
>> >> XmlConfigurator.Configure();
>> >>
>> >> GridServerBase.RunService(new GridServerBase(), args);
>> >>
>> >> //GridServerBase app = new GridServerBase();
>> >>
>> >> //app.Startup();
>> >> //app.Work();
>> >> }
>> >> Thats all.
>> >> --- You can now start your application with parameter '/Install' or
>> >> '/unistall' to create this service or to uninstall it.
>> >> --- You chose if it starts as a service and how its name an
>> >> dependencies
>> >> only in app.config of the diffrent projects.
>> >> If you dont want to run this as service switch in app.config.
>> >>
>> >>
>> >> Greetz
>> >>
>> >> Kai
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: opensim-dev-bounces at lists.berlios.de
>> >> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Kyle
>> >> Hamilton
>> >> Sent: Sonntag, 21. Dezember 2008 00:24
>> >> To: opensim-dev at lists.berlios.de
>> >> Subject: Re: [Opensim-dev] Feature Request ...
>> >>
>> >> You can also use srvany.exe from Microsoft to turn any .exe into a
>> >> service. http://www.iopus.com/guides/srvany.htm has information.
>> >>
>> >> -Kyle H
>> >>
>> >> On Sat, Dec 20, 2008 at 1:13 PM, Stefan Andersson
>> >> <stefan at tribalmedia.se> wrote:
>> >> > Excellent! We really need windows service wrappers for the various
>> >> exe's.
>> >> >
>> >> > A couple of pointers:
>> >> >
>> >> > 1) Since this is (in practice) a windows-only project, you should
>> >> implement
>> >> > this as a 'forge' project;
>> >> > http://forge.opensimulator.org/gf/
>> >> >
>> >> > 2) To be able to do so, you should implement the services as
>> >> 'wrappers',
>> >> > separate applications that _use_ the Main Classes, not change or
>> >> expand on
>> >> > them, like for example for the grid service wrapper:
>> >> >
>> >> > partial class GridServ : ServiceBase
>> >> > {
>> >> > private GridServerBase m_gridApplication;
>> >> >
>> >> > protected override void OnStart(string[] args)
>> >> > {
>> >> > // Define working directory (For a service, this is set
>> >> > to
>> >> > System dir by default...)
>> >> > Process pc = Process.GetCurrentProcess();
>> >> > string useDirectory = pc.MainModule.FileName.Substring(0,
>> >> > pc.MainModule.FileName.LastIndexOf(@"\"));
>> >> > Directory.SetCurrentDirectory(useDirectory);
>> >> > log4net.Config.XmlConfigurator.Configure();
>> >> > m_gridApplication = new GridServerBase();
>> >> > m_gridApplication.Startup();
>> >> > }
>> >> > }
>> >> >
>> >> > (This snippet taken from Tribal Medias proprietary service wrappers -
>> >> feel
>> >> > free to copy+paste.)
>> >> >
>> >> > 3) When you've done the wrappers, the next step is to add a method to
>> >> > communicate with the consoles. One way to go about it is to have the
>> >> service
>> >> > process redirect the console in and output to a named pipe, and then
>> >> supply
>> >> > a console app that listens/writes to those pipes.
>> >> >
>> >> > Best regards,
>> >> > Stefan Andersson
>> >> > Tribal Media AB
>> >> >
>> >> >
>> >> > ________________________________
>> >> > Date: Sat, 20 Dec 2008 19:53:32 +0100
>> >> > From: Develope at Ashuan.de
>> >> > To: Opensim-dev at lists.berlios.de
>> >> > Subject: [Opensim-dev] Feature Request ...
>> >> >
>> >> >
>> >> > Hi Friends,
>> >> >
>> >> >
>> >> >
>> >> > i wish to implement the feature to run all Gridcomponents
>> >> > (Userserver,
>> >> > Assetserver ....) as a Service.
>> >> >
>> >> > My work is now only to evaluate how easy or not it is ... it is easy
>> >> .. but
>> >> > ...
>> >> >
>> >> >
>> >> >
>> >> > I must add an Reference to the System.ServiceProcess in several
>> >> Project.
>> >> >
>> >> > Now my question ...
>> >> >
>> >> >
>> >> >
>> >> > Is there a Problem doing this?
>> >> >
>> >> > And second how do i include an reference into a .patch-File?
>> >> >
>> >> >
>> >> >
>> >> > Kai
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Opensim-dev mailing list
>> >> > Opensim-dev at lists.berlios.de
>> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >> >
>> >> >
>> >> _______________________________________________
>> >> Opensim-dev mailing list
>> >> Opensim-dev at lists.berlios.de
>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >> _______________________________________________
>> >> Opensim-dev mailing list
>> >> Opensim-dev at lists.berlios.de
>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >
>> >
>> > _______________________________________________
>> > Opensim-dev mailing list
>> > Opensim-dev at lists.berlios.de
>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >
>> >
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
More information about the Opensim-dev
mailing list