[Mono-dev] mono-service bugs

Avery Pennarun apenwarr at gmail.com
Mon Feb 4 12:14:59 EST 2008


Hi all,

I'm looking at fixing a few things related to writing a Windows
service in mono.  I'm currently working on mono 1.2.6 but plan to
upgrade to the latest svn shortly.

I have my service running fine, but as background, I've discovered at
least these problems:

1. mono-service runner doesn't catch SIGINT (it should clean up like
SIGTERM, and this is especially important when using the --debug
option).

2. When the lockfile already exists, we don't check to see if the pid
inside is valid before giving up.  The correct behaviour is to
kill(pid, 0) and see if we get ESRCH; if we do, the lock file is
invalid.  Combined with #1 the current behaviour is very silly.

3. Setting ServiceInstaller.Description and compiling in mono results
in a binary that doesn't work on .Net (no such method
set_Description).

4. Environment.UserInteractive should be false when run as a service
but true when run as a normal user; in Mono, it's always false (see
corlib/System/Environment.cs).

All of these are probably very easy fixes except #4, which is why I'm
asking here instead of just filing the bug or submitting a patch.
What does "interactive" mean in mono?  In Windows, it's a well-defined
concept (if you're not interactive, there's just no such thing as
stdout or stderr or popup dialogs etc; if you are interactive, then
there is).  In Unix, it's unclear: even daemons might have a stderr
(albeit not one they should usually be using) and even user-level
applications might not be able to pop up dialogs.

What I want is to be able to detect at runtime whether my program
should be a service (ie. call System.ServiceProcess.ServiceBase.Run)
or an application (ie. just do its thing in the foreground).  In
Windows, this is easy using Environment.UserInteractive, but in mono
it's not obvious.

I would be happy to submit a fix for Environment.UserInteractive, but
it's not obvious how we should do it.  Would checking for a valid
stdin work?  Or maybe it should always be true except when
mono-service explicitly makes it false somehow?  Does mono-service
have access to internal methods that would let it poke at environment
settings like that?

Thanks,

Avery



More information about the Mono-devel-list mailing list