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 attachment 51116 [details, diff] 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.
