From edwin at FreeBSD.org Mon Jun 2 14:30:09 2008 From: edwin at FreeBSD.org (edwin@FreeBSD.org) Date: Mon Jun 2 14:30:13 2008 Subject: ports/124208: Minor changes in www/mod_macro2 Message-ID: <200806021430.m52EU8Np012709@freefall.freebsd.org> Synopsis: Minor changes in www/mod_macro2 Responsible-Changed-From-To: freebsd-ports-bugs->apache Responsible-Changed-By: edwin Responsible-Changed-When: Mon Jun 2 14:30:08 UTC 2008 Responsible-Changed-Why: Over to maintainer (via the GNATS Auto Assign Tool) http://www.freebsd.org/cgi/query-pr.cgi?pr=124208 From jespasac at minibofh.org Wed Jun 4 16:08:11 2008 From: jespasac at minibofh.org (Jordi Espasa Clofent) Date: Wed Jun 4 16:08:17 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade Message-ID: <4846B64F.4090700@minibofh.org> Hi all, I think the subject is descriptive enough, but let me to explain again: Some days ago I've upgraded from 6.3 to 7.0. The only problem is when I do 'apachectl graceful' I get aways a Signal 11 fails. The /var/log/messages shows: [...] kernel: pid 90500 (httpd), uid 0: exited on signal 11 (core dumped) I've done some STFG and I found this interesting resource: http://www.zend.com/support/knowledgebase.php?kbid=173&view_only=1 But, unfortunately, it seems doesn't work. In another 6.3 boxes I've these values: kern.ipc.semmni: 10 kern.ipc.shmseg: 128 kern.ipc.shmmni: 192 kern.ipc.shmmin: 1 kern.ipc.shmmax: 33554432 I the 7.0 box the values are exactly _THE SAME_ and I get the error. Several tests I've done: * increase the shared memory using sysctl(8) on kern.ipc.shm* parameters. No successs. * reorder the PHP extensions as I've in 6.3 boxes. No success. Moreover, after upgrade the system (kernel+userland) I recompiled all the installed ports as official documentation advices (portupgrade -fa) Some useful info: # pkg_info -x apache Information for apache-2.0.63: Comment: Version 2 of Apache web server with prefork MPM. Required by: pecl-filter-0.11.0 pecl-hash-1.5 pecl-json-1.2.1 pecl-zip-1.9.0 php5-5.2.6 php5-ctype-5.2.6 php5-curl-5.2.6 php5-dom-5.2.6 php5-extensions-1.1 php5-gettext-5.2.6 php5-iconv-5.2.6 php5-mbstring-5.2.6 php5-mhash-5.2.6 php5-mysql-5.2.6 php5-mysqli-5.2.6 php5-openssl-5.2.6 php5-pcntl-5.2.6 php5-pcre-5.2.6 php5-pdo-5.2.6 php5-posix-5.2.6 php5-session-5.2.6 php5-simplexml-5.2.6 php5-spl-5.2.6 php5-tokenizer-5.2.6 php5-xml-5.2.6 php5-xmlreader-5.2.6 php5-xmlwriter-5.2.6 php5-zlib-5.2.6 squirrelmail-1.4.13 The crash analisys shows: root@mail01 [/usr/local/home/jespasac] [9:10] # gdb /usr/local/sbin/httpd -core /usr/crash/httpd.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `httpd'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libz.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.4 Reading symbols from /usr/local/lib/apache2/libaprutil-0.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/apache2/libaprutil-0.so.9 Reading symbols from /usr/local/lib/libexpat.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libexpat.so.6 Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/local/lib/apache2/libapr-0.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/apache2/libapr-0.so.9 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libcrypt.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.4 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/libexec/apache2/mod_access.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_access.so Reading symbols from /usr/local/libexec/apache2/mod_auth.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_auth.so Reading symbols from /usr/local/libexec/apache2/mod_auth_anon.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_auth_anon.so Reading symbols from /usr/local/libexec/apache2/mod_auth_dbm.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_auth_dbm.so Reading symbols from /usr/local/libexec/apache2/mod_charset_lite.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_charset_lite.so Reading symbols from /usr/local/libexec/apache2/mod_include.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_include.so Reading symbols from /usr/local/libexec/apache2/mod_deflate.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_deflate.so Reading symbols from /usr/local/libexec/apache2/mod_log_config.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_log_config.so Reading symbols from /usr/local/libexec/apache2/mod_logio.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_logio.so Reading symbols from /usr/local/libexec/apache2/mod_env.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_env.so Reading symbols from /usr/local/libexec/apache2/mod_mime_magic.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_mime_magic.so Reading symbols from /usr/local/libexec/apache2/mod_cern_meta.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_cern_meta.so Reading symbols from /usr/local/libexec/apache2/mod_expires.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_expires.so Reading symbols from /usr/local/libexec/apache2/mod_headers.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_headers.so Reading symbols from /usr/local/libexec/apache2/mod_usertrack.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_usertrack.so Reading symbols from /usr/local/libexec/apache2/mod_unique_id.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_unique_id.so Reading symbols from /usr/local/libexec/apache2/mod_setenvif.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_setenvif.so Reading symbols from /usr/local/libexec/apache2/mod_ssl.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_ssl.so Reading symbols from /usr/lib/libssl.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libssl.so.5 Reading symbols from /lib/libcrypto.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.5 Reading symbols from /usr/local/libexec/apache2/mod_mime.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_mime.so Reading symbols from /usr/local/libexec/apache2/mod_status.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_status.so Reading symbols from /usr/local/libexec/apache2/mod_autoindex.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_autoindex.so Reading symbols from /usr/local/libexec/apache2/mod_asis.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_asis.so Reading symbols from /usr/local/libexec/apache2/mod_info.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_info.so Reading symbols from /usr/local/libexec/apache2/mod_cgi.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_cgi.so Reading symbols from /usr/local/libexec/apache2/mod_vhost_alias.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_vhost_alias.so Reading symbols from /usr/local/libexec/apache2/mod_negotiation.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_negotiation.so Reading symbols from /usr/local/libexec/apache2/mod_dir.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_dir.so Reading symbols from /usr/local/libexec/apache2/mod_imap.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_imap.so Reading symbols from /usr/local/libexec/apache2/mod_actions.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_actions.so Reading symbols from /usr/local/libexec/apache2/mod_speling.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_speling.so Reading symbols from /usr/local/libexec/apache2/mod_userdir.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_userdir.so Reading symbols from /usr/local/libexec/apache2/mod_alias.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_alias.so Reading symbols from /usr/local/libexec/apache2/mod_rewrite.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/mod_rewrite.so Reading symbols from /usr/local/libexec/apache2/libphp5.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/libexec/apache2/libphp5.so Reading symbols from /usr/local/lib/libxml2.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x00000008064d62b0 in ?? () ??????? -- Thanks, Jordi Espasa Clofent From pgollucci at p6m7g8.com Thu Jun 5 05:12:52 2008 From: pgollucci at p6m7g8.com (Philip M. Gollucci) Date: Thu Jun 5 05:12:57 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade In-Reply-To: <4846B64F.4090700@minibofh.org> References: <4846B64F.4090700@minibofh.org> Message-ID: <484775D4.4090509@p6m7g8.com> Jordi Espasa Clofent wrote: > http://www.zend.com/support/knowledgebase.php?kbid=173&view_only=1 > kern.ipc.semmni: 10 > kern.ipc.shmseg: 128 > kern.ipc.shmmni: 192 > kern.ipc.shmmin: 1 > kern.ipc.shmmax: 33554432 > # pkg_info -x apache > Information for apache-2.0.63: Any chance of trying with www/apache22 ? > The crash analisys shows: > > root@mail01 [/usr/local/home/jespasac] [9:10] > Reading symbols from /usr/local/lib/apache2/libaprutil-0.so.9...(no > debugging symbols found)...done. You'll need to recompile with CFLAGS="-g" CFLAGS="-g" ./configure --enable-maintainer-mode > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x00000008064d62b0 in ?? () Did your paste buffer run out ? IF you repost, skip all the stuff above this line. -- ------------------------------------------------------------------------ Philip M. Gollucci (philip@ridecharge.com) o:703.549.2050x206 Senior System Admin - Riderway, Inc. http://riderway.com / http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. From jespasac at minibofh.org Thu Jun 5 16:53:26 2008 From: jespasac at minibofh.org (Jordi Espasa Clofent) Date: Thu Jun 5 16:53:29 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade In-Reply-To: <484775D4.4090509@p6m7g8.com> References: <4846B64F.4090700@minibofh.org> <484775D4.4090509@p6m7g8.com> Message-ID: <48481A02.2050502@minibofh.org> > Any chance of trying with www/apache22 ? Not possible at present moment because of several front-end panel. Maybe in near future. > You'll need to recompile with CFLAGS="-g" > CFLAGS="-g" ./configure --enable-maintainer-mode I've tried the next command portupgrade -f -m "WITH_DEBUG=1 CFLAGS=-g CONFIGURE_ARGS=--enable-maintainer-mode" apache without success: [...] Installing header files Installing man pages and online manual Installing build system files To run apache www server from startup, add apache2_enable="YES" in your /etc/rc.conf. Extra options can be found in startup script. *** Error code 1 Stop in /usr/ports/www/apache20. *** Error code 1 Stop in /usr/ports/www/apache20. ===> Cleaning for apache-2.0.63 ---> Cleaning out obsolete shared libraries -- Thanks, Jordi Espasa Clofent From llbutler at leobutler.com Fri Jun 6 17:09:16 2008 From: llbutler at leobutler.com (Lew Butler) Date: Fri Jun 6 17:09:19 2008 Subject: [Fwd: Bank Of America Fraud Verification] Message-ID: <48496A73.7050206@leobutler.com> -------- Original Message -------- Subject: Bank Of America Fraud Verification Date: Thu, 05 Jun 2008 15:40:24 -0700 From: Lew Butler To: freebsd-apache@freebsd.org I recd an email this date supposedly from BofA their email address is Bank of America requesting my account, password and which branch. Your local branch said it was not from B0fA and to report this to U. Lewis L Butler 2258 Orleans Drive Pinole,Ca 94564 Tel 5107242309 Email llbutler@leobutler.com From edwin at FreeBSD.org Sat Jun 7 14:30:09 2008 From: edwin at FreeBSD.org (edwin@FreeBSD.org) Date: Sat Jun 7 14:30:11 2008 Subject: ports/124375: www/mod_auth_kerb doesn't compile against heimdal Message-ID: <200806071430.m57EU8EX030804@freefall.freebsd.org> Synopsis: www/mod_auth_kerb doesn't compile against heimdal Responsible-Changed-From-To: freebsd-ports-bugs->apache Responsible-Changed-By: edwin Responsible-Changed-When: Sat Jun 7 14:30:08 UTC 2008 Responsible-Changed-Why: Over to maintainer (via the GNATS Auto Assign Tool) http://www.freebsd.org/cgi/query-pr.cgi?pr=124375 From cajunman4life at gmail.com Sat Jun 7 15:45:54 2008 From: cajunman4life at gmail.com (Aaron Graves) Date: Sat Jun 7 15:45:59 2008 Subject: FreeBSD Port: mod_cband-0.9.7.5_1 Message-ID: <329dbeac0806070817l660824c5udc7b87c7a1016403@mail.gmail.com> The main site for port www/mod_cband is listed as cband.linux.pl, however it appears that site has been down for a few months. There is an alternative location on the internet ( http://www.sfr-fresh.com/unix/privat/mod-cband-0.9.7.5.tgz) that works. Could this link perhaps be added as a secondary link? Also, I wonder what the long-term solution for this would be? As it appears the website has been offline for a while, it's possible the author will no longer be updating this port. At any rate, wanted to make you aware of the situation. Thanks for your time. Aaron Graves From sahil at tandon.net Sat Jun 7 16:07:52 2008 From: sahil at tandon.net (Sahil Tandon) Date: Sat Jun 7 16:07:54 2008 Subject: FreeBSD Port: mod_cband-0.9.7.5_1 In-Reply-To: <329dbeac0806070817l660824c5udc7b87c7a1016403@mail.gmail.com> References: <329dbeac0806070817l660824c5udc7b87c7a1016403@mail.gmail.com> Message-ID: <20080607154909.GB56339@shepherd> Aaron Graves wrote: > The main site for port www/mod_cband is listed as cband.linux.pl, however it > appears that site has been down for a few months. There is an alternative > location on the internet ( > http://www.sfr-fresh.com/unix/privat/mod-cband-0.9.7.5.tgz) that works. > Could this link perhaps be added as a secondary link? Sure. Make the change/addition yourself and submit a PR: -- Sahil Tandon From koitsu at FreeBSD.org Sat Jun 7 17:05:39 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat Jun 7 17:05:45 2008 Subject: FreeBSD Port: mod_cband-0.9.7.5_1 In-Reply-To: <20080607154909.GB56339@shepherd> References: <329dbeac0806070817l660824c5udc7b87c7a1016403@mail.gmail.com> <20080607154909.GB56339@shepherd> Message-ID: <20080607165830.GB11478@eos.sc1.parodius.com> On Sat, Jun 07, 2008 at 11:49:09AM -0400, Sahil Tandon wrote: > Aaron Graves wrote: > > > The main site for port www/mod_cband is listed as cband.linux.pl, however it > > appears that site has been down for a few months. There is an alternative > > location on the internet ( > > http://www.sfr-fresh.com/unix/privat/mod-cband-0.9.7.5.tgz) that works. > > Could this link perhaps be added as a secondary link? > > Sure. Make the change/addition yourself and submit a PR: That seems a bit excessive, being as the change is a single line. Aaron, no need to submit a PR; I've added the above URL to the MASTER_SITES and committed the change: ===== koitsu 2008-06-07 16:57:09 UTC FreeBSD ports repository Modified files: www/mod_cband Makefile Log: - Add a secondary entry to MASTER_SITES. Reported by: Aaron Graves Revision Changes Path 1.13 +2 -1 ports/www/mod_cband/Makefile ===== -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From cajunman4life at gmail.com Sat Jun 7 17:09:55 2008 From: cajunman4life at gmail.com (Aaron Graves) Date: Sat Jun 7 17:10:03 2008 Subject: FreeBSD Port: mod_cband-0.9.7.5_1 In-Reply-To: <20080607165830.GB11478@eos.sc1.parodius.com> References: <329dbeac0806070817l660824c5udc7b87c7a1016403@mail.gmail.com> <20080607154909.GB56339@shepherd> <20080607165830.GB11478@eos.sc1.parodius.com> Message-ID: <329dbeac0806071009h1cf4e14cm9436196ec3f863e9@mail.gmail.com> Awesome, thanks Jeremy. And I didn't know that after failing on the primary site it would fall-back to a copy on the FreeBSD ftp server. Now I know ;) Aaron On 6/7/08, Jeremy Chadwick wrote: > > On Sat, Jun 07, 2008 at 11:49:09AM -0400, Sahil Tandon wrote: > > Aaron Graves wrote: > > > > > The main site for port www/mod_cband is listed as cband.linux.pl, > however it > > > appears that site has been down for a few months. There is an > alternative > > > location on the internet ( > > > http://www.sfr-fresh.com/unix/privat/mod-cband-0.9.7.5.tgz) that > works. > > > Could this link perhaps be added as a secondary link? > > > > Sure. Make the change/addition yourself and submit a PR: > > > That seems a bit excessive, being as the change is a single line. > > Aaron, no need to submit a PR; I've added the above URL to the > MASTER_SITES and committed the change: > > ===== > koitsu 2008-06-07 16:57:09 UTC > > FreeBSD ports repository > > Modified files: > www/mod_cband Makefile > Log: > - Add a secondary entry to MASTER_SITES. > > Reported by: Aaron Graves > > Revision Changes Path > 1.13 +2 -1 ports/www/mod_cband/Makefile > ===== > > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > From koitsu at FreeBSD.org Sat Jun 7 17:10:39 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat Jun 7 17:10:41 2008 Subject: FreeBSD Port: mod_cband-0.9.7.5_1 In-Reply-To: <329dbeac0806070817l660824c5udc7b87c7a1016403@mail.gmail.com> References: <329dbeac0806070817l660824c5udc7b87c7a1016403@mail.gmail.com> Message-ID: <20080607165325.GA11478@eos.sc1.parodius.com> On Sat, Jun 07, 2008 at 08:17:27AM -0700, Aaron Graves wrote: > The main site for port www/mod_cband is listed as cband.linux.pl, however it > appears that site has been down for a few months. There is an alternative > location on the internet ( > http://www.sfr-fresh.com/unix/privat/mod-cband-0.9.7.5.tgz) that works. > Could this link perhaps be added as a secondary link? When the sites in MASTER_SITES have been exhausted, the ports system resorts to trying from one of the FreeBSD distfile masters, which should almost always contain a copy of the tarball. Case in point: icarus# make fetch => mod-cband-0.9.7.5.tgz doesn't seem to exist in /usr/ports/distfiles/apache2. => Attempting to fetch from http://cband.linux.pl/download/. fetch: http://cband.linux.pl/download/mod-cband-0.9.7.5.tgz: No address record => Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/apache2/. mod-cband-0.9.7.5.tgz 100% of 69 kB 293 kBps Does this not work for you? > Also, I wonder what the long-term solution for this would be? As it > appears the website has been offline for a while, it's possible the > author will no longer be updating this port. At any rate, wanted to > make you aware of the situation. Thanks for your time. No one knows how to reach the author of mod_cband. The only Email address made available was at the site which is now down. This isn't really FreeBSD's "problem", though. There isn't much the FreeBSD ports folks can do about reviving the cband.linux.pl site. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From bugmaster at FreeBSD.org Mon Jun 9 11:06:16 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 9 11:06:41 2008 Subject: Current problem reports assigned to apache@FreeBSD.org Message-ID: <200806091106.m59B6F5c070031@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o ports/124375 apache www/mod_auth_kerb doesn't compile against heimdal 1 problem total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o ports/124208 apache Minor changes in www/mod_macro2 1 problem total. From romain at blogreen.org Tue Jun 10 14:35:01 2008 From: romain at blogreen.org (Romain =?iso-8859-1?Q?Tarti=E8re?=) Date: Tue Jun 10 14:35:06 2008 Subject: Porting modules depending on a patched apache install Message-ID: <20080610141207.GA38613@marvin.blogreen.org> Hello I would like to give a try to mod_caldav [1], which depends on mod_dav_acl [2], which require a patched version of Apache to build and run. In other word, the mod_dav_acl tarball contains a patch that you have to apply to Apache source before you can build the module. I would like to know how to handle this situation if I want to create FreeBSD ports for these modules. Kind regards, Romain References: 1. http://sourceforge.net/projects/modcaldav 2. http://sourceforge.net/projects/moddavacl -- Romain Tarti?re http://romain.blogreen.org/ pgp: 8DAB A124 0DA4 7024 F82A E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43) (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-apache/attachments/20080610/0f52856e/attachment.pgp From pgollucci at p6m7g8.com Tue Jun 10 22:09:25 2008 From: pgollucci at p6m7g8.com (Philip M. Gollucci) Date: Tue Jun 10 22:09:30 2008 Subject: Porting modules depending on a patched apache install In-Reply-To: <20080610141207.GA38613@marvin.blogreen.org> References: <20080610141207.GA38613@marvin.blogreen.org> Message-ID: <484EFB93.9010304@p6m7g8.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Romain Tarti?re wrote: | Hello | | I would like to give a try to mod_caldav [1], which depends on | mod_dav_acl [2], which require a patched version of Apache to build and | run. | | In other word, the mod_dav_acl tarball contains a patch that you have to | apply to Apache source before you can build the module. | | | I would like to know how to handle this situation if I want to create | FreeBSD ports for these modules. | | Kind regards, | Romain | | References: | 1. http://sourceforge.net/projects/modcaldav | 2. http://sourceforge.net/projects/moddavacl 1) Realistically, you'd need to roll your own www/apacheXX+mod_dav_acl port and it would not be a SLAVE port of anyother www/apacheXX port. Then mod_caldav would BUILD/RUN_DEPENDS on that port. 2) You could try submitting a patch that does WITH_FOO_BAR=yes conditional to one the www/apacheXX ports. IF set, it applies your patch. Later, your mod_dav_acl would need to check somehow if that patch had been applied. If not, set IGNORE="Need www/apacheXX WITH_FOO_BAR support enabled" to stop the build. the mod_dav_acl port should always set the WITH_FOO_BAR=yes flag so that all of the following sequences would work: a) $ cd www/mod_cal_dav ; make b) $ cd www/mod_dav_acl ; make $ cd www/mod_cal_dav ; make c) $ cd /www/apacheXX ; make WITH_FOO_BAR=yes $ cd www/mod_dav_acl ; make $ cd www/mod_cal_dav ; make - -- - ------------------------------------------------------------------------ Philip M. Gollucci (philip@ridecharge.com) o:703.549.2050x206 Senior System Admin - Riderway, Inc. http://riderway.com / http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iD8DBQFITvuTdbiP+9ubjBwRAtopAJ9ihkZlat2/a7hL17seqStRDU9NkgCgkCQr Lb8Lpk6YFcmxqAP6uFtvm4U= =dCo+ -----END PGP SIGNATURE----- From jespasac at minibofh.org Wed Jun 11 15:51:23 2008 From: jespasac at minibofh.org (Jordi Espasa Clofent) Date: Wed Jun 11 15:51:28 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <48481A02.2050502@minibofh.org> References: <4846B64F.4090700@minibofh.org> <484775D4.4090509@p6m7g8.com> <48481A02.2050502@minibofh.org> Message-ID: <484FF478.8010405@minibofh.org> It seems a php-extensions bug. If you comment the mhash.so in /usr/local/etc/php/extensions.ini as: ;entension=mhash.so all works fine and you don't get anymore httpd crash (signal 11) if you use 'apachectl graceful'. Maybe will be a good idea to open PR for this? I hope it helps someone.... (I'm very surprised that this isn't a documented bug in 7.0 yet) -- Thanks, Jordi Espasa Clofent From koitsu at FreeBSD.org Wed Jun 11 16:28:07 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Jun 11 16:28:11 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <484FF478.8010405@minibofh.org> References: <4846B64F.4090700@minibofh.org> <484775D4.4090509@p6m7g8.com> <48481A02.2050502@minibofh.org> <484FF478.8010405@minibofh.org> Message-ID: <20080611161048.GA66773@eos.sc1.parodius.com> On Wed, Jun 11, 2008 at 05:51:20PM +0200, Jordi Espasa Clofent wrote: > It seems a php-extensions bug. > If you comment the mhash.so in /usr/local/etc/php/extensions.ini as: > > ;entension=mhash.so > > all works fine and you don't get anymore httpd crash (signal 11) if you > use 'apachectl graceful'. > > Maybe will be a good idea to open PR for this? > > I hope it helps someone.... (I'm very surprised that this isn't a > documented bug in 7.0 yet) Many people have reported that the *order* of the extensions in extensions.ini has adverse (positive) effects on PHP segfaults on FreeBSD. I myself haven't ever run into extension ordering issues like those described (and we've done hosting for years), but I don't doubt those who have experienced such. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From pgollucci at p6m7g8.com Wed Jun 11 20:05:54 2008 From: pgollucci at p6m7g8.com (Philip M. Gollucci) Date: Wed Jun 11 20:05:58 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <484FF478.8010405@minibofh.org> References: <4846B64F.4090700@minibofh.org> <484775D4.4090509@p6m7g8.com> <48481A02.2050502@minibofh.org> <484FF478.8010405@minibofh.org> Message-ID: <48503020.7010600@p6m7g8.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jordi Espasa Clofent wrote: | It seems a php-extensions bug. | If you comment the mhash.so in /usr/local/etc/php/extensions.ini as: | | ;entension=mhash.so | | all works fine and you don't get anymore httpd crash (signal 11) if you | use 'apachectl graceful'. | | Maybe will be a good idea to open PR for this? | | I hope it helps someone.... (I'm very surprised that this isn't a | documented bug in 7.0 yet) It might make more sense to follow up with php..... Just b/c it happens in 7.x and not 6.x doesn't mean its a FreeBSD issue. - -- - ------------------------------------------------------------------------ Philip M. Gollucci (philip@ridecharge.com) o:703.549.2050x206 Senior System Admin - Riderway, Inc. http://riderway.com / http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iD8DBQFIUDAgdbiP+9ubjBwRAskiAJ993ELYL3AP5HkVtDSk2JQx9OuJzACfdORO rnTL1Ecdd4MNwlcrNKhwLYM= =lX0o -----END PGP SIGNATURE----- From doconnor at gsoft.com.au Thu Jun 12 02:19:54 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Jun 12 02:19:58 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <20080611161048.GA66773@eos.sc1.parodius.com> References: <4846B64F.4090700@minibofh.org> <484FF478.8010405@minibofh.org> <20080611161048.GA66773@eos.sc1.parodius.com> Message-ID: <200806121118.45137.doconnor@gsoft.com.au> On Thu, 12 Jun 2008, Jeremy Chadwick wrote: > I myself haven't ever run into extension ordering issues like those > described (and we've done hosting for years), but I don't doubt those > who have experienced such. I am currently experiencing this :( In the past I shuffled the order until it worked but that's not a real solution. Also if you have gone from 6.x to 7.x make sure that you don't have any old stuff linked against libc.so.6 loaded into a binary using libc.so.7. It mostly works except with threaded programs and then *kaboom* -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-apache/attachments/20080612/b87b8a1d/attachment.pgp From lists at pingle.org Thu Jun 12 03:30:55 2008 From: lists at pingle.org (Jim Pingle) Date: Thu Jun 12 03:31:00 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <200806121118.45137.doconnor@gsoft.com.au> References: <4846B64F.4090700@minibofh.org> <484FF478.8010405@minibofh.org> <20080611161048.GA66773@eos.sc1.parodius.com> <200806121118.45137.doconnor@gsoft.com.au> Message-ID: <48509419.6060206@pingle.org> Daniel O'Connor wrote: > On Thu, 12 Jun 2008, Jeremy Chadwick wrote: >> I myself haven't ever run into extension ordering issues like those >> described (and we've done hosting for years), but I don't doubt those >> who have experienced such. > > I am currently experiencing this :( > In the past I shuffled the order until it worked but that's not a real > solution. > [snip] I've mentioned this on the lists a couple times, but I have a shell script I worked out that puts the extensions into a known-working order. http://www.pingle.org/2007/09/22/php-crashes-extensions-workaround It's based on things I've come across with respect to this issue over the last couple years. It's not a new problem by a long shot. It's been happening to me for years with PHP4 and PHP5, Apache 1.3.x and 2.x. See also my previous posts on my site: http://www.pingle.org/2006/10/18/php-crashes-extensions http://www.pingle.org/2007/05/13/php-crashes-extensions-2 And some previous threads on the topic: http://lists.freebsd.org/pipermail/freebsd-stable/2006-November/030951.html http://lists.freebsd.org/mailman/htdig/freebsd-ports/2006-November/036849.html (I thought there were more but I can't find them at the moment...) I need to see if I can improve the script any (suggestions are most welcome) then open a PR to see if it -- or logic like it -- can be included in the php-extensions meta port. Jim From doconnor at gsoft.com.au Thu Jun 12 04:18:23 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Jun 12 04:18:27 2008 Subject: Apache w/ PHP crashes after upgrading to 7.0 Message-ID: <200806121348.18205.doconnor@gsoft.com.au> Hi, I recently upgraded from FreeBSD 6.3 to 7.0 and now I am finding that it crashes on start unless I disable both pgsql.so and mhash.so. The stack trace is.. #0 0x28f04d40 in ?? () #1 0x281c6f2e in _pthread_main_np () from /lib/libc.so.7 #2 0x2819fa0c in puts () from /lib/libc.so.7 #3 0x281a0177 in gethostbyname () from /lib/libc.so.7 #4 0x08069a12 in ap_get_local_host () #5 0x08068b9c in ap_fini_vhost_config () #6 0x0805639c in ap_read_config () #7 0x0805f133 in standalone_main () #8 0x08060c1f in main () I am not sure why gethostbyname() would call puts() and why that would then crash though.. I am using apache+mod_ssl-1.3.41+2.8.31 php5-5.2.6 php5-gd-5.2.6 php5-gettext-5.2.6_1 php5-mbstring-5.2.6 php5-mhash-5.2.6 php5-openssl-5.2.6 php5-pcre-5.2.6 php5-pgsql-5.2.6_1 php5-session-5.2.6 php5-xml-5.2.6 php5-zlib-5.2.6 I have rebuilt them all and their dependents.. Please CC me as I am not subscribed to the list. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-apache/attachments/20080612/8a0dc930/attachment.pgp From doconnor at gsoft.com.au Thu Jun 12 05:15:38 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Jun 12 05:15:43 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <48509419.6060206@pingle.org> References: <4846B64F.4090700@minibofh.org> <200806121118.45137.doconnor@gsoft.com.au> <48509419.6060206@pingle.org> Message-ID: <200806121445.30864.doconnor@gsoft.com.au> On Thu, 12 Jun 2008, Jim Pingle wrote: > I need to see if I can improve the script any (suggestions are most > welcome) then open a PR to see if it -- or logic like it -- can be > included in the php-extensions meta port. Adding the script to the port seems like the way to go (baring an upstream fix but it seems like a difficult problem to solve). Unfortunately it doesn't help me :( If I disable everything except either pgsql or mhash (either separately or together) Apache crashes with.. #0 0x28ad6d40 in ?? () #1 0x281c6f2e in _pthread_main_np () from /lib/libc.so.7 #2 0x2819fa0c in puts () from /lib/libc.so.7 #3 0x281a0177 in gethostbyname () from /lib/libc.so.7 #4 0x08069a12 in ap_get_local_host () #5 0x08068b9c in ap_fini_vhost_config () #6 0x0805639c in ap_read_config () #7 0x0805f133 in standalone_main () #8 0x08060c1f in main () I don't understand why gethostbyname() would call puts() - and why that would then crash! Seems like some threading related wrinkle though as pgsql & mhash are the only extensions I have that are linked to libthr.so -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-apache/attachments/20080612/a537c6a6/attachment.pgp From koitsu at FreeBSD.org Thu Jun 12 05:59:19 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Jun 12 05:59:22 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <200806121445.30864.doconnor@gsoft.com.au> References: <4846B64F.4090700@minibofh.org> <200806121118.45137.doconnor@gsoft.com.au> <48509419.6060206@pingle.org> <200806121445.30864.doconnor@gsoft.com.au> Message-ID: <20080612055919.GA27267@eos.sc1.parodius.com> On Thu, Jun 12, 2008 at 02:45:21PM +0930, Daniel O'Connor wrote: > On Thu, 12 Jun 2008, Jim Pingle wrote: > > I need to see if I can improve the script any (suggestions are most > > welcome) then open a PR to see if it -- or logic like it -- can be > > included in the php-extensions meta port. > > Adding the script to the port seems like the way to go (baring an > upstream fix but it seems like a difficult problem to solve). > > Unfortunately it doesn't help me :( > If I disable everything except either pgsql or mhash (either separately > or together) Apache crashes with.. > > #0 0x28ad6d40 in ?? () > #1 0x281c6f2e in _pthread_main_np () from /lib/libc.so.7 > #2 0x2819fa0c in puts () from /lib/libc.so.7 > #3 0x281a0177 in gethostbyname () from /lib/libc.so.7 > #4 0x08069a12 in ap_get_local_host () > #5 0x08068b9c in ap_fini_vhost_config () > #6 0x0805639c in ap_read_config () > #7 0x0805f133 in standalone_main () > #8 0x08060c1f in main () > > I don't understand why gethostbyname() would call puts() - and why that > would then crash! I can't explain why it's calling puts() directly either. Bad RAM could cause something bizarre like this, or a corrupt/broken binary. The libc code I'm looking at (src/lib/libc/net/gethostnameadr.c and gethostbydns.c) don't call puts) don't appear to call puts() directly. Of course, there may be macros used which do this. There are some places in the resolver code where printing to stdout or stderr can occur. I'd expect to see a longer stack trace (meaning more functions between gethostbyname() and puts()) if that were the case, though. There's a decent document on how to debug httpd below. You'll need to start httpd with -X or with "MaxClients 1", to keep it from forking. You can do that through gdb if you want, or (what I prefer, since I'm not very good with gdb) use truss. http://httpd.apache.org/dev/debugging.html If you go the truss route, be sure to use -a -s 4096. You'd be able to see what actual string is being output via puts(), assuming it gets as far as to start writing data to the fd. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From doconnor at gsoft.com.au Thu Jun 12 07:05:50 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Jun 12 07:05:55 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <20080612055919.GA27267@eos.sc1.parodius.com> References: <4846B64F.4090700@minibofh.org> <200806121445.30864.doconnor@gsoft.com.au> <20080612055919.GA27267@eos.sc1.parodius.com> Message-ID: <200806121635.36998.doconnor@gsoft.com.au> On Thu, 12 Jun 2008, Jeremy Chadwick wrote: > > I don't understand why gethostbyname() would call puts() - and why > > that would then crash! > > I can't explain why it's calling puts() directly either. Bad RAM > could cause something bizarre like this, or a corrupt/broken binary. Yeah.. I have rebuilt lots of stuff, although not libc. This machine has build world, kernel, KDE, etc.. I am pretty sure the hardware is OK as none of the builds had an issue. > The libc code I'm looking at (src/lib/libc/net/gethostnameadr.c and > gethostbydns.c) don't call puts) don't appear to call puts() > directly. Of course, there may be macros used which do this. I had a look - there certainly isn't anywhere obvious it's hapening. I guess the only thing now is to rebuild with debugging. > There are some places in the resolver code where printing to stdout > or stderr can occur. I'd expect to see a longer stack trace (meaning > more functions between gethostbyname() and puts()) if that were the > case, though. > > There's a decent document on how to debug httpd below. You'll need > to start httpd with -X or with "MaxClients 1", to keep it from > forking. You can do that through gdb if you want, or (what I prefer, > since I'm not very good with gdb) use truss. OK thanks. > http://httpd.apache.org/dev/debugging.html > > If you go the truss route, be sure to use -a -s 4096. You'd be able > to see what actual string is being output via puts(), assuming it > gets as far as to start writing data to the fd. Hmm I had a go with gdb but it doesn't work properly.. I got this.. [midget 16:33] /tmp/work/usr/ports/www/apache13-modssl/work/apache_1.3.41 >sudo gdb src/httpd Password: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... (gdb) run -X Starting program: /data/tmp/work/usr/ports/www/apache13-modssl/work/apache_1.3.41/src/httpd -X [New LWP 100212] [New Thread 0x819d300 (LWP 100212)] [New LWP 100212] suspend error: generic error [Switching to LWP 100212] Stopped due to shared library event (gdb) info thread Cannot find new threads: generic error (gdb) bt #0 0x2807fda0 in r_debug_state () from /libexec/ld-elf.so.1 #1 0x2808367d in dlclose () from /libexec/ld-elf.so.1 #2 0x28706164 in zend_hash_apply_deleter () from /usr/local/libexec/apache/libphp5.so #3 0x287063a8 in zend_hash_graceful_reverse_destroy () from /usr/local/libexec/apache/libphp5.so #4 0x286fc89e in zend_shutdown () from /usr/local/libexec/apache/libphp5.so #5 0x286bb5bf in php_module_shutdown () from /usr/local/libexec/apache/libphp5.so #6 0x286bb66b in php_module_shutdown_wrapper () from /usr/local/libexec/apache/libphp5.so #7 0x28776aaa in apache_php_module_shutdown_wrapper () from /usr/local/libexec/apache/libphp5.so #8 0x080524d9 in ap_clear_pool (a=0x8106010) at alloc.c:1937 #9 0x0805f0f6 in standalone_main (argc=Variable "argc" is not available. ) at http_main.c:5480 #10 0x08060c1f in main (argc=-716130182, argv=0x1) at http_main.c:5883 I tried truss and it seemed to be taking a long time (5-10 minutes) and generating a lot of seemingly identical logging :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-apache/attachments/20080612/4f7514e1/attachment.pgp From koitsu at FreeBSD.org Thu Jun 12 07:28:12 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Jun 12 07:28:15 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <200806121635.36998.doconnor@gsoft.com.au> References: <4846B64F.4090700@minibofh.org> <200806121445.30864.doconnor@gsoft.com.au> <20080612055919.GA27267@eos.sc1.parodius.com> <200806121635.36998.doconnor@gsoft.com.au> Message-ID: <20080612072812.GA35851@eos.sc1.parodius.com> On Thu, Jun 12, 2008 at 04:35:26PM +0930, Daniel O'Connor wrote: > On Thu, 12 Jun 2008, Jeremy Chadwick wrote: > > > I don't understand why gethostbyname() would call puts() - and why > > > that would then crash! > > > > I can't explain why it's calling puts() directly either. Bad RAM > > could cause something bizarre like this, or a corrupt/broken binary. > > Yeah.. I have rebuilt lots of stuff, although not libc. Huh? > This machine has build world, kernel, KDE, etc.. I am pretty sure the hardware is OK as none of the builds had an issue. libc is part of world. *Every* program relies (is linked with) on libc. > > If you go the truss route, be sure to use -a -s 4096. You'd be able > > to see what actual string is being output via puts(), assuming it > > gets as far as to start writing data to the fd. > > Hmm I had a go with gdb but it doesn't work properly.. I got this.. > [midget 16:33] /tmp/work/usr/ports/www/apache13-modssl/work/apache_1.3.41 >sudo gdb src/httpd > Password: > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > (gdb) run -X > Starting program: /data/tmp/work/usr/ports/www/apache13-modssl/work/apache_1.3.41/src/httpd -X > [New LWP 100212] > [New Thread 0x819d300 (LWP 100212)] > [New LWP 100212] > suspend error: generic error > [Switching to LWP 100212] > Stopped due to shared library event > (gdb) info thread > Cannot find new threads: generic error > (gdb) bt > #0 0x2807fda0 in r_debug_state () from /libexec/ld-elf.so.1 > #1 0x2808367d in dlclose () from /libexec/ld-elf.so.1 > #2 0x28706164 in zend_hash_apply_deleter () > from /usr/local/libexec/apache/libphp5.so > #3 0x287063a8 in zend_hash_graceful_reverse_destroy () > from /usr/local/libexec/apache/libphp5.so > #4 0x286fc89e in zend_shutdown () from /usr/local/libexec/apache/libphp5.so > #5 0x286bb5bf in php_module_shutdown () from /usr/local/libexec/apache/libphp5.so > #6 0x286bb66b in php_module_shutdown_wrapper () > from /usr/local/libexec/apache/libphp5.so > #7 0x28776aaa in apache_php_module_shutdown_wrapper () > from /usr/local/libexec/apache/libphp5.so > #8 0x080524d9 in ap_clear_pool (a=0x8106010) at alloc.c:1937 > #9 0x0805f0f6 in standalone_main (argc=Variable "argc" is not available. > ) at http_main.c:5480 > #10 0x08060c1f in main (argc=-716130182, argv=0x1) at http_main.c:5883 I can't say much about this, but I'm willing to bet it's the result of some Apache + PHP weirdness. I've never known gdb on FreeBSD to be as reliable/useful as, say, on Linux or Solaris. Always odd/strange things happening with gdb on FreeBSD. > I tried truss and it seemed to be taking a long time (5-10 minutes) and > generating a lot of seemingly identical logging :( Okay, let's backtrack here. The OP states that he can induce a segfault of httpd when doing "apachectl graceful". Is that the exact problem you're seeing, or are you seeing problems where PHP/Apache segfaults during operation? I just want to be clear. If the latter, then truss "generating lots of seemingly identical logging" is probably expected. I'm guessing it's select() or poll() or something related to kqueue/kevent, as it'd be waiting for I/O on the HTTP socket. You'd have to submit the HTTP request to the PHP script to get it to crash. In either case, you may have to resort to using ktrace + kdump, which may or may not help narrow this down. Use "ktrace -i -t+ httpd -X" (I hope that'll work; I'm not sure if ktrace allows you to pass arguments to a command), which will start populating a file called ktrace.out. You should then do the "apachectl graceful" in another window (or if the latter, submit the HTTP request), and ktrace may exit when the segfault happens (I'm not sure about this; it may sit there indefinitely). In the case it doesn't exit, and you've confirmed the core happened (check "dmesg"), you should ^C the ktrace and then do "ktrace -C" just to be sure nothing got wedged. You'll then have to use kdump to decode the contents of ktrace.out. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From doconnor at gsoft.com.au Thu Jun 12 08:18:34 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Jun 12 08:18:39 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <20080612072812.GA35851@eos.sc1.parodius.com> References: <4846B64F.4090700@minibofh.org> <200806121635.36998.doconnor@gsoft.com.au> <20080612072812.GA35851@eos.sc1.parodius.com> Message-ID: <200806121748.28133.doconnor@gsoft.com.au> On Thu, 12 Jun 2008, Jeremy Chadwick wrote: > > Yeah.. I have rebuilt lots of stuff, although not libc. > > Huh? Sorry, I meant that I have to explicitly rebuilt it since I did a buildworld to make sure it wasn't fubar'd somehow. I haven't done that mainly because I find it extremely unlikely it would only break Apache in this manner but nothing else. I might rebuild it to get debug symbols though.. > > This machine has build world, kernel, KDE, etc.. I am pretty sure > > the hardware is OK as none of the builds had an issue. > > libc is part of world. *Every* program relies (is linked with) on > libc. Yes, sorry for my confusing turn of phrase! :) > > #10 0x08060c1f in main (argc=-716130182, argv=0x1) at > > http_main.c:5883 > > I can't say much about this, but I'm willing to bet it's the result > of some Apache + PHP weirdness. I've never known gdb on FreeBSD to > be as reliable/useful as, say, on Linux or Solaris. Always > odd/strange things happening with gdb on FreeBSD. Yeah :( > > I tried truss and it seemed to be taking a long time (5-10 minutes) > > and generating a lot of seemingly identical logging :( > > Okay, let's backtrack here. > > The OP states that he can induce a segfault of httpd when doing > "apachectl graceful". Is that the exact problem you're seeing, or > are you seeing problems where PHP/Apache segfaults during operation? > I just want to be clear. > > If the latter, then truss "generating lots of seemingly identical > logging" is probably expected. I'm guessing it's select() or poll() > or something related to kqueue/kevent, as it'd be waiting for I/O on > the HTTP socket. You'd have to submit the HTTP request to the PHP > script to get it to crash. > > In either case, you may have to resort to using ktrace + kdump, which > may or may not help narrow this down. > > Use "ktrace -i -t+ httpd -X" (I hope that'll work; I'm not sure if > ktrace allows you to pass arguments to a command), which will start > populating a file called ktrace.out. You should then do the > "apachectl graceful" in another window (or if the latter, submit the > HTTP request), and ktrace may exit when the segfault happens (I'm not > sure about this; it may sit there indefinitely). > > In the case it doesn't exit, and you've confirmed the core happened > (check "dmesg"), you should ^C the ktrace and then do "ktrace -C" > just to be sure nothing got wedged. > > You'll then have to use kdump to decode the contents of ktrace.out. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-apache/attachments/20080612/675d6a8d/attachment.pgp From doconnor at gsoft.com.au Thu Jun 12 08:20:54 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Jun 12 08:21:01 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <20080612072812.GA35851@eos.sc1.parodius.com> References: <4846B64F.4090700@minibofh.org> <200806121635.36998.doconnor@gsoft.com.au> <20080612072812.GA35851@eos.sc1.parodius.com> Message-ID: <200806121750.50756.doconnor@gsoft.com.au> [This is a continuation of my last message, I accidentally mashed the send key] On Thu, 12 Jun 2008, Jeremy Chadwick wrote: > > I tried truss and it seemed to be taking a long time (5-10 minutes) > > and generating a lot of seemingly identical logging :( > > Okay, let's backtrack here. > > The OP states that he can induce a segfault of httpd when doing > "apachectl graceful". Is that the exact problem you're seeing, or > are you seeing problems where PHP/Apache segfaults during operation? > I just want to be clear. No, I don't see a problem with 'apachectl graceful' - it doesn't get that far. > If the latter, then truss "generating lots of seemingly identical > logging" is probably expected. I'm guessing it's select() or poll() > or something related to kqueue/kevent, as it'd be waiting for I/O on > the HTTP socket. You'd have to submit the HTTP request to the PHP > script to get it to crash. I get a crash when Apache starts up. I wasn't sure if it was related to OPs problem or not, I should have been clearer though. > In either case, you may have to resort to using ktrace + kdump, which > may or may not help narrow this down. > > Use "ktrace -i -t+ httpd -X" (I hope that'll work; I'm not sure if > ktrace allows you to pass arguments to a command), which will start Yes ktrace does allow that. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-apache/attachments/20080612/7dc89d73/attachment.pgp From pgollucci at p6m7g8.com Thu Jun 12 08:27:04 2008 From: pgollucci at p6m7g8.com (Philip M. Gollucci) Date: Thu Jun 12 08:27:09 2008 Subject: Apache w/ PHP crashes after upgrading to 7.0 In-Reply-To: <200806121348.18205.doconnor@gsoft.com.au> References: <200806121348.18205.doconnor@gsoft.com.au> Message-ID: <4850DDD5.7090209@p6m7g8.com> Daniel O'Connor wrote: > Hi, > I recently upgraded from FreeBSD 6.3 to 7.0 and now I am finding that it > crashes on start unless I disable both pgsql.so and mhash.so. > > The stack trace is.. > #0 0x28f04d40 in ?? () > #1 0x281c6f2e in _pthread_main_np () from /lib/libc.so.7 > #2 0x2819fa0c in puts () from /lib/libc.so.7 > #3 0x281a0177 in gethostbyname () from /lib/libc.so.7 > #4 0x08069a12 in ap_get_local_host () > #5 0x08068b9c in ap_fini_vhost_config () > #6 0x0805639c in ap_read_config () > #7 0x0805f133 in standalone_main () > #8 0x08060c1f in main () That stack trace is bogus looks like memory/stack got corrupted.... gethostbyname does not call puts() 8-current code: src/lib/libc/net/gethostnameadr.c: struct hostent * gethostbyname(const char *name) { struct hostdata *hd; struct hostent *rval; int ret_h_errno; if ((hd = __hostdata_init()) == NULL) return (NULL); if (gethostbyname_r(name, &hd->host, hd->data, sizeof(hd->data), &rval, &ret_h_errno) != 0) return (NULL); return (rval); } Rather than gdb binary binary.core trying doing $ gdb /usr/local/sbin/httpd http://httpd.apache.org/dev/debugging.html#gdb see the url for the rest.... -- ------------------------------------------------------------------------ Philip M. Gollucci (philip@ridecharge.com) o:703.549.2050x206 Senior System Admin - Riderway, Inc. http://riderway.com / http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. From lists at pingle.org Thu Jun 12 11:21:31 2008 From: lists at pingle.org (Jim Pingle) Date: Thu Jun 12 11:21:34 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <200806121445.30864.doconnor@gsoft.com.au> References: <4846B64F.4090700@minibofh.org> <200806121118.45137.doconnor@gsoft.com.au> <48509419.6060206@pingle.org> <200806121445.30864.doconnor@gsoft.com.au> Message-ID: <485106B6.7050805@pingle.org> Daniel O'Connor wrote: > On Thu, 12 Jun 2008, Jim Pingle wrote: >> I need to see if I can improve the script any (suggestions are most >> welcome) then open a PR to see if it -- or logic like it -- can be >> included in the php-extensions meta port. > > Adding the script to the port seems like the way to go (baring an > upstream fix but it seems like a difficult problem to solve). > > Unfortunately it doesn't help me :( > If I disable everything except either pgsql or mhash (either separately > or together) Apache crashes with.. > > #0 0x28ad6d40 in ?? () > #1 0x281c6f2e in _pthread_main_np () from /lib/libc.so.7 > #2 0x2819fa0c in puts () from /lib/libc.so.7 > #3 0x281a0177 in gethostbyname () from /lib/libc.so.7 > #4 0x08069a12 in ap_get_local_host () > #5 0x08068b9c in ap_fini_vhost_config () > #6 0x0805639c in ap_read_config () > #7 0x0805f133 in standalone_main () > #8 0x08060c1f in main () > > I don't understand why gethostbyname() would call puts() - and why that > would then crash! > > Seems like some threading related wrinkle though as pgsql & mhash are > the only extensions I have that are linked to libthr.so > I'm afraid I wouldn't be much help with this one in that case. I have a vague recollection of gethostbyname() crashing for someone else, though. I thought it had something to do with the ServerName directive and/or an entry in /etc/hosts -- but unfortunately I don't recall the specifics and my Google-fu seems to be failing me this morning. Jim From doconnor at gsoft.com.au Thu Jun 12 13:16:17 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Jun 12 13:16:26 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <485106B6.7050805@pingle.org> References: <4846B64F.4090700@minibofh.org> <200806121445.30864.doconnor@gsoft.com.au> <485106B6.7050805@pingle.org> Message-ID: <200806122246.09852.doconnor@gsoft.com.au> On Thu, 12 Jun 2008, Jim Pingle wrote: > > Seems like some threading related wrinkle though as pgsql & mhash > > are the only extensions I have that are linked to libthr.so > > I'm afraid I wouldn't be much help with this one in that case. I have > a vague recollection of gethostbyname() crashing for someone else, > though. I thought it had something to do with the ServerName > directive and/or an entry in /etc/hosts -- but unfortunately I don't > recall the specifics and my Google-fu seems to be failing me this > morning. I did some googling on the stack trace and found.. http://www.nabble.com/php5-and-postgresql-8.2-8.3-td16744979.html I think I'll try switching to Apache 2.. (Right after I upgrade my mail system so I can ditch any 6.x cruft ) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-apache/attachments/20080612/caae0382/attachment.pgp From scf at FreeBSD.org Thu Jun 12 15:17:36 2008 From: scf at FreeBSD.org (Sean C. Farley) Date: Thu Jun 12 15:17:39 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <200806121118.45137.doconnor@gsoft.com.au> References: <4846B64F.4090700@minibofh.org> <484FF478.8010405@minibofh.org> <20080611161048.GA66773@eos.sc1.parodius.com> <200806121118.45137.doconnor@gsoft.com.au> Message-ID: On Thu, 12 Jun 2008, Daniel O'Connor wrote: > On Thu, 12 Jun 2008, Jeremy Chadwick wrote: >> I myself haven't ever run into extension ordering issues like those >> described (and we've done hosting for years), but I don't doubt those >> who have experienced such. > > I am currently experiencing this :( In the past I shuffled the order > until it worked but that's not a real solution. > > Also if you have gone from 6.x to 7.x make sure that you don't have > any old stuff linked against libc.so.6 loaded into a binary using > libc.so.7. > > It mostly works except with threaded programs and then *kaboom* Also, please try rebuilding PHP5 that has this fix[1] (in ports tree after June 9th). It may or may not help your issue. Sean 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/123911 -- scf@FreeBSD.org From doconnor at gsoft.com.au Sat Jun 14 14:54:21 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Sat Jun 14 14:54:24 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: References: <4846B64F.4090700@minibofh.org> <200806121118.45137.doconnor@gsoft.com.au> Message-ID: <200806150024.13198.doconnor@gsoft.com.au> On Fri, 13 Jun 2008, Sean C. Farley wrote: > On Thu, 12 Jun 2008, Daniel O'Connor wrote: > > On Thu, 12 Jun 2008, Jeremy Chadwick wrote: > >> I myself haven't ever run into extension ordering issues like > >> those described (and we've done hosting for years), but I don't > >> doubt those who have experienced such. > > > > I am currently experiencing this :( In the past I shuffled the > > order until it worked but that's not a real solution. > > > > Also if you have gone from 6.x to 7.x make sure that you don't have > > any old stuff linked against libc.so.6 loaded into a binary using > > libc.so.7. > > > > It mostly works except with threaded programs and then *kaboom* > > Also, please try rebuilding PHP5 that has this fix[1] (in ports tree > after June 9th). It may or may not help your issue. > > Sean > 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/123911 I tried that but no luck :( I can build php5 with pgsql (ie modify the port Makefile) and then it works and so does mhash(?!) - I am using that as a work around ATM. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-apache/attachments/20080614/f89cbebb/attachment.pgp From bugmaster at FreeBSD.org Mon Jun 16 11:06:16 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 16 11:06:45 2008 Subject: Current problem reports assigned to apache@FreeBSD.org Message-ID: <200806161106.m5GB6FWB035959@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o ports/124375 apache www/mod_auth_kerb doesn't compile against heimdal 1 problem total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o ports/124208 apache Minor changes in www/mod_macro2 1 problem total. From bugmaster at FreeBSD.org Mon Jun 23 11:06:17 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 23 11:06:28 2008 Subject: Current problem reports assigned to apache@FreeBSD.org Message-ID: <200806231106.m5NB6GL4064205@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o ports/124375 apache www/mod_auth_kerb doesn't compile against heimdal 1 problem total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o ports/124208 apache Minor changes in www/mod_macro2 1 problem total. From itetcu at FreeBSD.org Fri Jun 27 15:20:52 2008 From: itetcu at FreeBSD.org (QA Tindy) Date: Fri Jun 27 15:20:54 2008 Subject: www/apache13-ssl - bad plist Message-ID: <20080627180252.423e0480@it.buh.tecnik93.com> Hi, You receive this email if you are either the maintainer of the port or if you recently committed to it. If the error is already fixed please ignore this email; if you submit a PR to fix it CC me and I'll commit it ASAP. The builds are done under tinderbox-2.4.3, on 7-STABLE on amd64, with tinderd_flags="-nullfs -plistcheck -onceonly" and ccache support, with the official up-to-date Ports Tree (for commit-triggered builds the files are fetched via CVSWeb), with the following vars set: NOPORTDOCS=yes, NOPORTEXAMPLES=yes, NOPORTDATA=yes, FORCE_PACKAGE=yes. The error which triggered this email is bellow followed by the link to the full log and explanations about the testing process. building apache+ssl-1.3.41.1.59 in directory /var/tinderbox/7-STABLE-FTP maintained by: apache@FreeBSD.org building for: 7.0-STABLE amd64 port directory: /usr/ports/www/apache13-ssl Makefile ident: $FreeBSD: ports/www/apache13-ssl/Makefile,v 1.122 2008/04/15 11:50:10 dinoex Exp $ prefixes: LOCALBASE=usr/local X11BASE=usr/local NO* env vars: NOPORTDOCS=yes NOPORTEXAMPLES=yes NOPORTDATA=yes build started at Fri Jun 27 14:59:51 UTC 2008 ...... 7161459 28 -rw-r--r-- 1 root wheel 13363 Jan 10 17:00 usr/local/share/doc/apache/server-wide.html.fr 7161462 24 -rw-r--r-- 1 root wheel 11683 Jan 10 17:00 usr/local/share/doc/apache/server-wide.html.html 7161463 28 -rw-r--r-- 1 root wheel 12457 Jan 10 17:00 usr/local/share/doc/apache/server-wide.html.ja.jis 7161464 20 -rw-r--r-- 1 root wheel 9917 Jan 10 17:00 usr/local/share/doc/apache/sitemap.html 7161465 28 -rw-r--r-- 1 root wheel 12289 Jan 10 17:00 usr/local/share/doc/apache/sourcereorg.html 7161467 20 -rw-r--r-- 1 root wheel 9531 Jan 10 17:00 usr/local/share/doc/apache/stopping.html.en 7161468 28 -rw-r--r-- 1 root wheel 12828 Jan 10 17:00 usr/local/share/doc/apache/stopping.html.fr 7161469 20 -rw-r--r-- 1 root wheel 9647 Jan 10 17:00 usr/local/share/doc/apache/stopping.html.html 7161470 48 -rw-r--r-- 1 root wheel 23056 Jan 10 17:00 usr/local/share/doc/apache/suexec.html.en 7161471 48 -rw-r--r-- 1 root wheel 23172 Jan 10 17:00 usr/local/share/doc/apache/suexec.html.html 7161472 48 -rw-r--r-- 1 root wheel 24562 Jan 10 17:00 usr/local/share/doc/apache/suexec.html.ja.jis 7161473 16 -rw-r--r-- 1 root wheel 7631 Jan 10 17:00 usr/local/share/doc/apache/suexec_1_2.html 7161474 8 -rw-r--r-- 1 root wheel 2814 Jan 10 17:00 usr/local/share/doc/apache/unixware.html 7161475 32 -rw-r--r-- 1 root wheel 15141 Jan 10 17:00 usr/local/share/doc/apache/upgrading_to_1_3.html 7161478 28 -rw-r--r-- 1 root wheel 12972 Jan 10 17:00 usr/local/share/doc/apache/urlmapping.html 7161482 4 drwxr-xr-x 2 root wheel 1024 Jan 10 17:00 usr/local/share/doc/apache/vhosts 7161483 36 -rw-r--r-- 1 root wheel 18358 Jan 10 17:00 usr/local/share/doc/apache/vhosts/details.html 7161484 36 -rw-r--r-- 1 root wheel 17599 Jan 10 17:00 usr/local/share/doc/apache/vhosts/details_1_2.html 7161485 44 -rw-r--r-- 1 root wheel 21154 Jan 10 17:00 usr/local/share/doc/apache/vhosts/examples.html 7161486 8 -rw-r--r-- 1 root wheel 2962 Jan 10 17:00 usr/local/share/doc/apache/vhosts/fd-limits.html.en 7161487 8 -rw-r--r-- 1 root wheel 3078 Jan 10 17:00 usr/local/share/doc/apache/vhosts/fd-limits.html.html 7161489 8 -rw-r--r-- 1 root wheel 3368 Jan 10 17:00 usr/local/share/doc/apache/vhosts/fd-limits.html.ja.jis 7161493 4 -rw-r--r-- 1 root wheel 204 Jan 10 17:00 usr/local/share/doc/apache/vhosts/footer.html 7161494 4 -rw-r--r-- 1 root wheel 319 Jan 10 17:00 usr/local/share/doc/apache/vhosts/header.html 7161495 20 -rw-r--r-- 1 root wheel 8691 Jan 10 17:00 usr/local/share/doc/apache/vhosts/host.html 7161496 8 -rw-r--r-- 1 root wheel 3326 Jan 10 17:00 usr/local/share/doc/apache/vhosts/index.html.en 7161497 8 -rw-r--r-- 1 root wheel 3442 Jan 10 17:00 usr/local/share/doc/apache/vhosts/index.html.html 7161498 8 -rw-r--r-- 1 root wheel 3507 Jan 10 17:00 usr/local/share/doc/apache/vhosts/index.html.ja.jis 7161499 16 -rw-r--r-- 1 root wheel 6274 Jan 10 17:00 usr/local/share/doc/apache/vhosts/ip-based.html 7161500 36 -rw-r--r-- 1 root wheel 16700 Jan 10 17:00 usr/local/share/doc/apache/vhosts/mass.html 7161501 24 -rw-r--r-- 1 root wheel 10928 Jan 10 17:00 usr/local/share/doc/apache/vhosts/name-based.html.en 7161502 24 -rw-r--r-- 1 root wheel 11044 Jan 10 17:00 usr/local/share/doc/apache/vhosts/name-based.html.html 7161503 28 -rw-r--r-- 1 root wheel 12730 Jan 10 17:00 usr/local/share/doc/apache/vhosts/name-based.html.ja.jis 7161504 36 -rw-r--r-- 1 root wheel 17599 Jan 10 17:00 usr/local/share/doc/apache/vhosts/vhosts-in-depth.html 7161505 20 -rw-r--r-- 1 root wheel 9681 Jan 10 17:00 usr/local/share/doc/apache/vhosts/virtual-host.html 7161513 56 -rw-r--r-- 1 root wheel 27470 Jan 10 17:00 usr/local/share/doc/apache/windows.html.en 7161506 24 -rw-r--r-- 1 root wheel 11633 Jan 10 17:00 usr/local/share/doc/apache/win_compiling.html.en 7161507 24 -rw-r--r-- 1 root wheel 11749 Jan 10 17:00 usr/local/share/doc/apache/win_compiling.html.html 7161508 28 -rw-r--r-- 1 root wheel 13195 Jan 10 17:00 usr/local/share/doc/apache/win_compiling.html.ja.jis 7161509 40 -rw-r--r-- 1 root wheel 18681 Jan 10 17:00 usr/local/share/doc/apache/win_service.html.en 7161510 40 -rw-r--r-- 1 root wheel 18797 Jan 10 17:00 usr/local/share/doc/apache/win_service.html.html 7161511 44 -rw-r--r-- 1 root wheel 21652 Jan 10 17:00 usr/local/share/doc/apache/win_service.html.ja.jis 7161514 56 -rw-r--r-- 1 root wheel 27586 Jan 10 17:00 usr/local/share/doc/apache/windows.html.html 7161515 64 -rw-r--r-- 1 root wheel 31275 Jan 10 17:00 usr/local/share/doc/apache/windows.html.ja.jis ================================================================ build of /usr/ports/www/apache13-ssl ended at Fri Jun 27 15:01:23 UTC 2008 http://t64.tecnik93.com/errors/7-STABLE-FTP/apache+ssl-1.3.41.1.59.log These emails are generated in one of the following cases: - an automated build was scheduled because the port was touched in CVS - the periodic QA build has reached it. - the port was scheduled because it is a dependency of a port from the cases above. There is no fixed interval for this; if other ports depend on it you will receive this emails more often since testing those other ports is made impossible by this port being broken. Efforts are made to restrict the number of outgoing emails to one/port/week for QA or dependency builds (but not for commit-triggered builds; if you commit 3 times in 5 minutes to the same port and the first 2 versions fail you'll receive 2 emails). When you fix install/plist errors please bear in mind that each of the 3 NO* vars controls the installation of different type of files, so constructs like: .ifndef NOPORTDOCS @${MKDIR} ${DATADIR} ... .endif or %%PORTDOCS%%%%EXAMPLESDIR%%/some_example_file are WRONG. Please use the right pairs like: %%PORTDOCS%%%%DOCSDIR%% %%PORTEXAMPLES%%%%EXAMPLESDIR%% %%PORTDATA%%%%DATADIR%% Thanks for your work on making FreeBSD better, -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B From itetcu at FreeBSD.org Sat Jun 28 07:25:24 2008 From: itetcu at FreeBSD.org (QA Tindy) Date: Sat Jun 28 07:25:26 2008 Subject: www/mod_curb - bad plist Message-ID: <20080628102522.03084471@it.buh.tecnik93.com> Hi, You receive this email if you are either the maintainer of the port or if you recently committed to it. If the error is already fixed please ignore this email; if you submit a PR to fix it CC me and I'll commit it ASAP. The builds are done under tinderbox-2.4.3, on 7-STABLE on amd64, with tinderd_flags="-nullfs -plistcheck -onceonly" and ccache support, with the official up-to-date Ports Tree (for commit-triggered builds the files are fetched via CVSWeb), with the following vars set: NOPORTDOCS=yes, NOPORTEXAMPLES=yes, NOPORTDATA=yes, FORCE_PACKAGE=yes. The error which triggered this email is bellow followed by the link to the full log and explanations about the testing process. building mod_curb-1.1 in directory /var/tinderbox/7-STABLE-FTP maintained by: apache@FreeBSD.org building for: 7.0-STABLE amd64 port directory: /usr/ports/www/mod_curb Makefile ident: $FreeBSD: ports/www/mod_curb/Makefile,v 1.4 2005/12/04 14:08:56 clement Exp $ prefixes: LOCALBASE=usr/local X11BASE=usr/local NO* env vars: NOPORTDOCS=yes NOPORTEXAMPLES=yes NOPORTDATA=yes build started at Sat Jun 28 06:29:43 UTC 2008 ...... ======================================== ===> Building package for mod_curb-1.1 Creating package /tmp/packages/All/mod_curb-1.1.tbz Registering depends: apache-1.3.41 perl-5.8.8_1 expat-2.0.1. Creating bzip'd tar ball in '/tmp/packages/All/mod_curb-1.1.tbz' Deleting mod_curb-1.1 Don't forget to remove all mod_curb-related directives in your httpd.conf ================================================================ === Checking filesystem state list of extra files and directories in / (not present before this port was installed but present after it was deinstalled) 7162979 4 drwxr-xr-x 2 root wheel 512 Jun 28 06:30 usr/local/share/doc/mod_curb 7162980 4 -r--r--r-- 1 root wheel 1551 Jun 28 06:30 usr/local/share/doc/mod_curb/README ================================================================ build of /usr/ports/www/mod_curb ended at Sat Jun 28 06:30:00 UTC 2008 http://t64.tecnik93.com/errors/7-STABLE-FTP/mod_curb-1.1.log These emails are generated in one of the following cases: - an automated build was scheduled because the port was touched in CVS - the periodic QA build has reached it. - the port was scheduled because it is a dependency of a port from the cases above. There is no fixed interval for this; if other ports depend on it you will receive this emails more often since testing those other ports is made impossible by this port being broken. Efforts are made to restrict the number of outgoing emails to one/port/week for QA or dependency builds (but not for commit-triggered builds; if you commit 3 times in 5 minutes to the same port and the first 2 versions fail you'll receive 2 emails). When you fix install/plist errors please bear in mind that each of the 3 NO* vars controls the installation of different type of files, so constructs like: .ifndef NOPORTDOCS @${MKDIR} ${DATADIR} ... .endif or %%PORTDOCS%%%%EXAMPLESDIR%%/some_example_file are WRONG. Please use the right pairs like: %%PORTDOCS%%%%DOCSDIR%% %%PORTEXAMPLES%%%%EXAMPLESDIR%% %%PORTDATA%%%%DATADIR%% Thanks for your work on making FreeBSD better, -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B From bugmaster at FreeBSD.org Mon Jun 30 11:06:16 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 30 11:06:26 2008 Subject: Current problem reports assigned to apache@FreeBSD.org Message-ID: <200806301106.m5UB6Fed094983@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o ports/124375 apache www/mod_auth_kerb doesn't compile against heimdal 1 problem total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o ports/124208 apache Minor changes in www/mod_macro2 1 problem total. From eric.cope at gmail.com Mon Jun 30 16:11:23 2008 From: eric.cope at gmail.com (Eric Cope) Date: Mon Jun 30 16:11:26 2008 Subject: WebDAV on FreeBSD Message-ID: Hello all, I was not sure which mailing list to use, so I guessed this one. I am trying to use webDAV with Apache. The Apache version is 2.2.3. I have the module enabled. I can not get access. I have webDAV running on a Ubuntu machine. I compared the conf files. They are very similar. The FreeBSD machine has some more modules enabled. Thats about the only difference. Has anyone else successfully run webDAV on a FreeBSD machine? What else do I need to share to get this working? Thanks, Eric From pgollucci at p6m7g8.com Mon Jun 30 16:31:45 2008 From: pgollucci at p6m7g8.com (Philip M. Gollucci) Date: Mon Jun 30 16:31:49 2008 Subject: WebDAV on FreeBSD In-Reply-To: References: Message-ID: <48690A6F.2040001@p6m7g8.com> Eric Cope wrote: > Hello all, > I was not sure which mailing list to use, so I guessed this one. I am > trying to use webDAV with Apache. The Apache version is 2.2.3. I have the > module enabled. I can not get access. I have webDAV running on a Ubuntu > machine. I compared the conf files. They are very similar. The FreeBSD > machine has some more modules enabled. Thats about the only difference. Has > anyone else successfully run webDAV on a FreeBSD machine? What else do I > need to share to get this working? > Thanks, It should be pretty straight forward. cd /usr/ports/www/apache22 make all install clean WITH_FULLBUILD=yes LoadModule dav_module libexec/apache22/mod_dav.so LoadModule dav_fs_module libexec/apache22/mod_dav_fs.so Then you just need a Location block. http://httpd.apache.org/docs/2.2/mod/mod_dav.html