Bugzilla Bug 77169

When I run apache2 with "-D MONO" set in /etc/conf.d/apache2, mod_mono should
run mod-mono-server when needed and create the /tmp/mod_mono_server socket to
let mod_mono communicate with the clr.

On my machine the socket isn't created and mod-mono-server is not spawned.

I tried to set "MonoRunXSP True" in
/etc/apache2/conf/modules.d/70_mod_mono.conf but it doesn't work.

I'm running:
Mono JIT compiler version 1.0.5, (C) 2002-2004 Novell, Inc and Contributors.
www.go-mono.com
        TLS:           __thread
        GC:            Included Boehm (with typed GC)
        SIGSEGV      : altstack
        Globalization: ICU

xsp.exe 1.0.5.0
(c) 2002,2003 Ximian, Inc.
(c) 2003,2004 Novell, Inc.
Minimalistic web server for testing System.Web

www-apache/mod_mono-1.0.5 

net-www/apache-2.0.52-r1 


Reproducible: Always
Steps to Reproduce:
1. Emerge mod_mono
2. Add -D MONO in /etc/conf.d/apache2
3. [Re]start apache2

Actual Results:  
mod-mono-server isn't spawned when required.

Expected Results:  
mod-mono-server should have started and created a /tmp/mod_mono_server socket.

jormangund@bifrost jormangund $ emerge info
Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.4.3,
glibc-2.3.4.20040808-r1,
2.6.10-gentoo-r2-bifrost i686)
=================================================================
System uname: 2.6.10-gentoo-r2-bifrost i686 AMD Athlon(tm) XP 2100+
Gentoo Base System version 1.4.16
Autoconf: sys-devel/autoconf-2.59-r5
Automake: sys-devel/automake-1.8.5-r1
Binutils: sys-devel/binutils-2.15.90.0.1.1-r3
Headers:  sys-kernel/linux26-headers-2.6.8.1-r2
Libtools: sys-devel/libtool-1.5.2-r7
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O2 -march=athlon-xp -mtune=athlon-xp -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
COMPILER=""
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon-xp -mtune=athlon-xp -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms"
GENTOO_MIRRORS="ftp://mirrors.tds.net/gentoo http://mirror.datapipe.net/gentoo
ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo ftp://mir.zyrianes.net/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 3dnow X acl alsa apm arts avi berkdb bitmap-fonts cdr crypt cscope
cups
dvd dvdr encode esd fam flac foomaticdb gdbm gif gnome gpm gstreamer gtk gtk2
imlib jpeg junit libwww mad mcal mikmod mmx motif mpeg mysql ncurses nptl
oggvorbis opengl oss pam pdflib perl png python quicktime readline samba sdl
slang spell sse ssl svga tcpd tiff truetype xml xml2 xmms xv zlib"

I used ps to check the running processes, and I found this:

0 S    81 18209     1 TS   24 -  9525 322524 ?          0:00 /usr/bin/mono /usr/lib/mono/1.0/mod-mono-server.exe --filename /tmp/mod_mono_server --applications /mono:/usr/share/doc/xsp/test --nonstop --appconfigdir /etc/apache2/conf/mod-mono-applications
1 S    81 18210 18209 TS   24 -  3977 -      ?          0:00 /usr/bin/mono /usr/lib/mono/1.0/mod-mono-server.exe --filename /tmp/mod_mono_server --applications /mono:/usr/share/doc/xsp/test --nonstop --appconfigdir /etc/apache2/conf/mod-mono-applications

So, mod-mono-server.exe is running, but still the socket doesn't exist.

Anything abnormal in the error log(s)?  Anything unusually different in your
set-up that might affect listening on a local socket in /tmp (SELinux, for
example)?

All I get in /var/log/apache2/error_log is:

[Sun Jan 23 19:11:27 2005] [error] Failed connecting. No such file or directory

I don't use any security subsystem, besides the "default Linux capabilities" kernel module.

I did re-emerge apache2 without the "threads" USE flag and it works well now.
The socket is created and the examples work.

Okay, more and more people are reporting this (upstream, on IRC, ...) so I'm
reopening this.  Can we get confirmation that only threaded MPM's are affected
by this bug? :-)

Yeah, this definitely deserves to still be open, at least for a little while as
a reference. The ximian bug at http://bugzilla.ximian.com/show_bug.cgi?id=68854
more details on the problem.

I'm considering the best way to handle this, as obviously the mod_mono package
doesn't want to go around adding things to the apache/apache2 init script
willy-nilly.

This definitely at least needs some information at the end of the mod_mono
install of apache is installed with this flag enabled. Other thoughts on the
best way to handle this?

Peter, thanks muchly for the link to the Ximian bug - I totally missed that
while hunting earlier. :-)

I'd be inclined to die if USE=threads/some-threaded-mpm (in the p.mask'ed
apache ebuild), as currently mod_mono is apparently useless with anything but
prefork.  If that's too drastic (likely ;-), hows about adding the folloing to
pkg_setup():

  if use some-threaded-mpm; then
    ewarn "mod_mono currently has issues with threaded MPM's."
    ewarn "If you experience problems, please report them on bug #N"
    ewarn
    ewarn "You may also want to consider re-emerging net-www/apache"
    ewarn "with USE=mpm-prefork"
    ...
  (USE flag names would have to be adjusted if the p.mask'ed apache hasn't gone
stable, typo's removed, etc. ;-)

?

I think it should be more adequate to check if apache was emerged with the
"threads" USE flag (or any other flag stated above) because such a flag could
have been included only for apache:

USE="threads" emerge apache

but this same USE flag could simply be turned off while emerging mod_mono.

Is there a way to do that? Like, in /var/db/pkg/net-www/apace-xxx-xxx-xx/USE
???

if APACHE2_MT_UNSAFE is set and the MPM isn't prefork, then the following
happens in apache-module eclass:

               eerror "You currently have Apache configured to use the."
                eerror "$APACHE2_MPM_STYLE MPM style.  The module you are"
                eerror "trying to install is not currently thread-safe,"
                eerror "and will not work under your current configuraiton."
                echo
                eerror "If you still want to use the module, please reinstall"
                eerror "Apache with mpm-prefork set."

                epause
                ebeep
                die Invalid Apache MPM style.

If a module isn't thread safe, it should probably just set APACHE2_MT_UNSAFE.
(I beleive this check was added for mod_php, but was decided to be general
enough to be in the eclass)

Thanks Michael, I totally forgot about that var! :-)  That suits mod_mono's
need perfectly.  Only problem is: what do we do in the mean time (i.e., while
the Apache ebuilds are still p.mask'ed)?  Just ewarn the user that headaches
may follow if Apache USE'd threads?

The "mean time" will be rather short. We should be coming out of p.mask rather
soon... within a week or two at the most.

Okay, after ripping apart my dev-station and installing unstable mono, xsp and
mod_mono (1.0.5-r3, 1.0.5-r1 and 1.0.5, respectively), I've still got no
problems, apart from a very, very slight race condition (this setup has been
pretty much okay since 1.0.2, so I don't think this is a regression).

The race happens when apache exec's mod-mono-server, which can result in having
to send one or more requests out, before which it will fail until
mod-mono-server has been actually had time to start (at least, that's how many
requests it took here, and that only happened 2 out of 5 times - mod_mono was
up and ready, after I sent the requests, for the other three tries).

There's also another bug, which cropped up with the move from /usr/bin/*.exe ->
/usr/lib/mono/1.0 (affects people that didn't change MonoExecutablePath to
/bin/sh when the assembly was moved, and a shell script wrapper added  to
/usr/bin - perhaps that's just me ;).  By default, mono (the runtime) will try
and interpret the shell-script, which was a no-go. :)

I'll work on a patch that add's a few nanosleep/stat calls to the request
handler which'll hopefully mitigate things; likewise, I'll upload a patch here
asap for the breakage in default configuration settings for mod_mono.  latexer,
if the patches are sound, would it be possible to get them committed to the
tree? :)

In the mean-time, can everyone that's experiencing this problem please check
that /tmp/.wapi (or wherever you set MonoWapiDir to) is writable by the user
that apache runs as (that's the 'apache' user, by default) - if not, run "chown
-R apache /tmp/.wapi && chmod 0700 /tmp/.wapi".  (You might also want to remove
the files under /tmp.wapi, ymmv).

Once you've got that done, if your still having problems, could you check if
the to-be-attached example config works for you (you'll have to replace the
hostnames, paths, etc. with your own).  Remember, until patched, you'll have to
give Apache a chance to start-up mod-mono-server after sending the first
request.

Thanks,

Created an attachment (id=51116) [edit]
Example working configuration for mod_mono.

Please give 1.0.6 a try. Upstream has included a fix, need confirmation here.
Thanks.

Marking NEEDINFO. Please report if mod_mono-1.0.6 fixes your problems. Thanks.

Neither 1.0.6 nor 1.0.6-r1 work for me. 
Mod-mono-server runs fine when started manually, but it doesn't work
when called by apache (2.0.53 - apache shows that mod_mono is loaded,
but there's no socket in /tmp, asp.net pages don't work).
Same happens with XSP, it doesn't create socket when I use init.d script,
but started from console everything seems to work ok.

Portage 2.0.51.20-r4 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r6 i686)
=================================================================
System uname: 2.6.11-gentoo-r6 i686 Intel(R) Pentium(R) 4 CPU 1.70GHz
Gentoo Base System version 1.4.16
dev-lang/python:     2.3.4-r1
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.4
sys-devel/binutils:  2.15.92.0.2-r7
sys-devel/libtool:   1.5.14
virtual/os-headers:  2.6.8.1-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=pentium3 -mcpu=pentium4 -O2 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=pentium3 -mcpu=pentium4 -O2 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo"
LANG="pl_PL"
LC_ALL="pl_PL"
LINGUAS="pl"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/local/bmg-main"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X alsa apache2 apm arts avi berkdb bitmap-fonts cdr crypt cups curl emboss encode esd flac foomaticdb fortran gdbm gif gnome gpm gstreamer gtk gtk2 imagemagick imlib ipv6 java jpeg ldap libg++ libwww mad mikmod mmx mono motif mozilla moznocompose moznoirc moznomail mp3 mpeg mysql ncurses nls ogg oggvorbis opengl oss pam pdflib perl png python quicktime readline sdl slang spell sse ssl svga tcpd tetex tiff truetype truetype-fonts type1-fonts usb vorbis xml2 xv zlib linguas_pl"
Unset:  ASFLAGS, CTARGET, LDFLAGS

Issue seems to be fixed (at least partially) with latest stable apache2
release in portage. Installed packages:
net-www/apache-2.0.54-r2
dev-lang/mono-1.1.7
dev-dotnet/xsp-1.0.8
www-apache/mod_mono-1.0.8-r1

Now when I set MonoRunXSP to 'True' and start apache with init.d script, mod-mono-server works fine (socket file is created in /tmp), but I'm getting 
those warnings in apache error_log:

[Thu May 12 15:38:26 2005] [notice] Apache/2.0.54 (Gentoo/Linux) mod_mono/1.0.8 configured -- resuming normal operations
Another mod-mono-server with the same arguments is already running.
Another mod-mono-server with the same arguments is already running.
Another mod-mono-server with the same arguments is already running.
Another mod-mono-server with the same arguments is already running.

New xsp and mod_mono ebuilds are now in portage. Could you please check if this
behaviour is still present when using those new versions?

It works fine with newest xsp/mod_mono versions. Closing.