[Mono-dev] mono-service bugs
jonpryor at vt.edu
Mon Feb 4 14:12:48 EST 2008
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
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
> 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
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.
More information about the Mono-devel-list