Turns out this was more my issue than mono-service ... though I think mono-service still might want to handle things more elegantly?
The problem is I have a worker object with internal threading that gets kicked off with Worker.Start(). The issue is I was accidentally calling it twice: once in the constructor of the service class and once in the OnStart override. Removing the call from the ctor fixed me. However, when the bug was present, the service did start fine but the lock file was never written. I'll see if I can create a simple test case and see if client code is causing the issues and whether or not mono-service might be improved. Thanks for the patience! -Abe On Tue, Oct 26, 2010 at 6:57 AM, Jörg Rosenkranz <[email protected]> wrote: > Hi Abe, > > 2010/10/25 Abe Gillespie <[email protected]> >> >> > Yes, well, it notes: >> > >> > -l:<lock file> Lock file (default is /tmp/<service>.lock) >> > >> > But not only is it lying about the default, using the switch doesn't >> > work either. And the script doesn't do anything specifically about >> > setting the lock file; this is done from within mono-service.exe >> > directly. >> > > > According to > http://github.com/mono/mono/blob/master/mcs/tools/mono-service/mono-service.cs > the -l switch is still supported, and the default location is still /tmp. > Could you make sure that the wrapper script in your case provides the switch > to the EXE? > > Joerg. > _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
