[Mono-dev] mono-service bugs

[Jonathan Pryor]

On Mon, 2008-02-04 at 12:14 -0500, Avery Pennarun wrote:
> 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).

Not as easy as you'd think; check the archives with the "Control-C
handler" subject.  To reliably catch SIGINT/SIGTERM/etc., you'll need to
use UnixSignal, which was just added to svn-HEAD.  If I'm lucky, I'll
get the tests written to permit it to go into 1.9 soon.

> 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 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.

Mono itself doesn't close stdin, stdout, or stderr, so even a
mono-service-based app will still have stdin/stdout/stderr (unless/until
mono-service actually closes those file descriptors).

> 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?

Unless mono-service is modified to close stdin, this won't work.

>   Or maybe it should always be true except when
> mono-service explicitly makes it false somehow?

This makes more sense.

>   Does mono-service
> have access to internal methods that would let it poke at environment
> settings like that?

You can [DllImport("__Internal")] to obtain functions within the mono
executable, or (better) you can add an internal call to Mono that
mono-service would make use of.  Environment.UserInteractive could then
use a different internal call to obtain the value of some variable,
permitting communication (via internal calls) between mono-service and
System.Environment.  This is likely the best solution.

 - Jon